2021.09.10 REST API HTTP Method

2021.09.10 REST API HTTP Method_ 정리노트

 

 오랜만이지..? 그동안 나는 간단한 사이드 프로젝트 하면서 지냈음..! 탱자탱자 놀진 않았고, 간단하게 django , html,css 로 팀원들과 사이드프로젝트 하면서 지냈더라는 근황~~~

 

사실 그래서 해당 사이드 프로젝트 관련으로 전전날부터 포스팅을 슬슬 준비하고 있다가.. 어 이건 정말 포스팅,, 해도 되나 싶을정도로 야매 코드라서 임시저장으로 남겨둠 ㅎㅅㅎ..

 

---

 

그러다가 간만에 리.다.기 읽으면서 백엔드 node.js 에 대한 것들을 그냥 주욱 따라 치다가 오랜만에 rest api 관련 개념이 나오길래 흠.. 역시 조금 딥하게 알고 싶어서 오늘은 간단하게 rest api http method 중심으로 rest api 설계시 따라야하는 중심 규칙 ? 도 같이 포스팅 해볼 예정..! 

 

뭔가 카테고리를 따로 파기엔 애매해스 고냥 drf 카테고리로 넣은거지 딱히 drf 랑은 상관 X~~~

 

 

https://korinkorin.tistory.com/54

2021.05.04 django restframework tutorial

 

 

이 포스팅에서 잠시 몇 줄로 다뤄왔던 REST API 를 오늘은 조금 더 이해하기 위해서 정리해보자!!!

 

쨋든 저기서도 말했듯이 우리가 웹 애플리케이션을 만들려면 데이터베이스에서 정보를 입력하고 읽어와야 하는데, 웹 브라우저에서 직접 데이터베이스에 접속하여 데이터를 변경하게 되면 보안상 문제가 된다. 그래서 우리는 REST API 를 사용해서 데이터의 정보를 클라이언트와 주고 받을 수 있다. 

 

그렇다면 왜 REST API ?

HTTP 설계의 우수성에 비해서 제대로 사용되어지지 못하기 때문에 웹의 장점을 최대한 활용할 수 있게 하기 위해 REST 라는 아키텍처를발표하여 일을 쉽고 멋지게 하기 위함!

 

그렇다면 HTTP 도 빠지지 않고 정리해봅자. 구조도 역시나 간단하게! ㄱ!

---

 

HTTP (HyperText Trasfer Protocol)

하이퍼 텍스트 (HTML) 문서를 교환하기 위해 만들어진 통신규약. (protocol)

웹상에서 네트워크로 서버끼리 통신을 할 때 어떻게 통신을 할 것인지에 대해서 규정해놓은 통신 형식 또는 통신구조.

프론트엔드 서버와 클라이언트 간의 통신에도 사용되고, 백엔드랑 프론트엔드 서버 간의 통신에도 사용.

 

통신 방식

기본적으로 요청(request) / 응답 ( response ) 구조.

클라이언트와 서버의 모든 통신은 요청과 응답으로 이루어진다.

클라이언트가 request 를 서버에 보내면 서버는 HTTP response 를 보내는 구조.

HTTP 는 상태를 저장하지 않는 stateless. 즉, 요청이 오면 그에 응답할뿐, 요청/응답끼리 서로 연결되어 있지 않음. 

클라이언트가 전과 똑같은 요청을 보낸다해도, 전에 보냈던 응답에 대해 알지 못하기 때문에 서로 독립적인 응답/요청이 되는 것.

그래서 여러 요청과 응답의 진행과정이나 데이터가 필요할 때는 쿠키나 세션을 사용한다.

 

 

HTTP request 구조

ㅎㅇㅎㅇ 오래전 postman 을 꺼냈다. 관련 글을 읽다가 아이 터미널은 어렬워 하고 생각해보니 API 요청 보낼 때 POSTMAN 많이 쓰자너. 나도 저번에 썼고 그럼 이 구조겠네 ? 싶어서 가져옴. 헤헤 역시 이렇게 보니까 조금 편하당.

 

HTTP request 메세지는 크게 3가지 구조로 나뉘어져있다. 

 

start line

HTTP request의 첫 라인

얘 또한 3가지로 구성. 

POST /create HTTP/1.1

HTTP method / Request target/HTTP Version

요롷게!

 

create 를 할 때 메소드는 POST 일 것이고, Request target 은 해당 request 가 전송되는 uri 라네 여기서는 예시를 들면 /create 이런너낌. 마지막으로 HTTP Version 역시 말그대로 사용되는 HTTP 버전을 말함.

 

 

headers

해당 요청에 대한 추가 정보를 담고 있는 부분.

Key:Value  값으로 되어있다. 

헤더도 크게 3부분으로 나뉘는데 오늘은 3부분으로 나눠지는거만 기억하고 자주 사용되는 정보만 정리.

 

Host
요청이 전송되는 target의 host url: 예를 들어, google.com

 

User-Agent
요청을 보내는 클라이언트의 대한 정보: 예를 들어, 웹브라우저에 대한 정보

 

Accept
해당 요청이 받을 수 있는 응답(response) 타입

 

Connection
해당 요청이 끝난후에 클라이언트와 서버가 계속해서 네트워크 컨넥션을 유지 할것인지 아니면 끊을것인지에 대해 지시하는 부분

 

Content-Type
해당 요청이 보내는 메세지 body의 타입. 예를 들어, JSON을 보내면 application/json.

 

 

Content-Length
메세지 body의 길이

 

 

음음 이렇게 postman 으로 보면서 정리하니 더 쉽구만. 이렇게 포스트맨에서도 보면 Key Value 로 데이터를 요청해서 보낼 수 있다. 

 

 

 

body

해당 reqeust의 실제 메세지/내용.
Body가 없는 request도 많다
예로,GET 은 url 파라미터에 요청하는 데이터를 담아보내기 때문에 body 가 없음. POST 는 body 에 데이터를 담아보낸다.

 

요 postman 은 user create 라서 내가 POST 요청을 보냈기 때문에 body 가 존재한다. 

 

 

 

HTTP response 구조

얘도 request 와 마찬가지로 크게 3가지 구조로 나뉜다. 

 

status line

response 의 상태를 간략하게 나타내주는 부분. 얘도 3부분으로 구성!

 

Response의 상태를 간략하게 나타내주는 부분.
3부분으로 구성되어 있다.

 

HTTP/1.1 404 Not Found​

 

HTTP 버전/ Status code /Status text

여기서의 예시로 버전은 1.1로 나타내고 있고 응답상태를 나타내는 status code 는 404. 응답 상태를 나타내는 status code 는 Not Found 가 된다!

 

 

headers

저거.. 옛날꺼 캡쳐한거라서 헤더탭으로 들어가지 못해서 슬프균 저 프로젝트 이미 폐기했음..끌끌 쨋든 근데 얘도 request 헤더랑 똑같음! 

다만 response 에서만 쓰는 헤더들이 있다.

User-Agent 대신에 Server 헤더가 대신 쓰이는 경우 등등

 

 

body

얘도 마찬가지로 postman 보면 알겠지만 일반적으로 동일하고 얘 또한 모든 response 가 body 가 필수로 있는 것은 아님.

데이터를 전송할 필요가 없다면 body 는 비어있게 된다.

 

https://velog.io/@teddybearjung/HTTP-%EA%B5%AC%EC%A1%B0-%EB%B0%8F-%ED%95%B5%EC%8B%AC-%EC%9A%94%EC%86%8C

HTTP 구조 및 핵심 요소

 

여기가면 정말 더 자세히 설명해주셨음 되게 잘 읽었습니다..! 꾸벅꾸

---

 

rest api 관련 글을 읽다가 URI 규칙이 머야? URL 이랑 다른건가 싶어서 또또 혼자서 구글링구글링

 

URI (Uniform Resource Identifier)

특정 리소스를 식별하는 통합 자원 식별자.

웹 기술에서 사용하는 논리적 또는 물리적 리소스를 식별하는 고유한 문자열 시퀀스.

 

 

URL 

쉽게 말하면 웹 주소. 컴퓨터 네트워크 상에서 리소스가 어디 있는지 알려주기 위한 규악.

URI 의 서브셋.

 

그러니까 URL 보다 큰 개념 즉, 식별자로서의 개념이 URI!

비유하자면,

'korin' 은 식별자로 쓰이기 때문에 URI

'부산시 어디어디구 어디어디동' 은 실제 주소의 경로를 가리키기 때문에 URL!

 

 

https://www.korin.com/index.html

얘는 index.html 파일이 들어있는 실제 경로이기 때문에 URL이자, URI

 

http://www.korin.com/index

얘는 이 경로에 index라는 파일이 웹 서버에 존재하지 않으므로 URL 은 아니지만 index 라는 식별자를 통해 처리해서 index.html 을 불러 올 수 있으므로 URI 는 정답!

 

 

음음 가릿가릿 URI 가 좀 더 큰 바운더리에 있으며, 그 바운더리 안에 경로를 뜻하는 URL 이 있는거여써 i got it~

 

 

---

 

짜아 다시 돌아와서 그럼 기본적인 CRUD 를 할 때 쓰는 HTTP method 들을 살펴보면서 중심 규칙 살짝 맛보기.

 

HTTP method 

GET	해당 리소스를 조회. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져옴.  쉽게 말해서 데이터를 조회할 때 사용!
POST	해당 URI 요청 시, 리소스를 생성함. 데이터를 등록할 때 사용
DELETE	데이터를 삭제할 때 사용.
PUT	데이터를 새 정보로 통째로 교체할 때 사용.
PATCH	데이터의 특정 필드를 수정할 때 사용.

 

역시 뭐하나 그냥 사용하는게 없었다고 한다

 

 

 

총 정리!

URI 는 정보의 자원을 표현해야하며, 자원에 대한 행위는 HTTP Method 로 표현하는 것이 REST 한 API 를 설계하는 중심 규칙!

 

 

예시를 보며, 한번 더 이해!

 

URI 는 정보의 자원을 표현해야 한다. 리소스의 이름은 동사보다는 명사를 사용하자.

GET /members/delete/1     (X)

 

얘는 REST 하지 않아!!!! 얘는 자원을 표현하는데 중점을 두지 않고 지우겠다는 행위를 URI 로 표현한 것이다. 요것은 정답이 아님.

 

 

 DELETE /members/1     (O)

 

이렇게 행위에 대한 것은 DELETE 메소드로 표현해야 하는 것이 정답!

 

 

회원 정보를 가져올 때

GET /members/show/1     (x)
GET /members/1          (o)

 

삐삐 - show 는 얘를 조회해서 보여주겠다라는 행위라서 오답.

GET 메서드를 사용해서 데이터를 조회할건데, 멤버정보를 조회하겠다. 정답~

 

 

회원을 추가할 때

GET /members/insert/2 (x)  
POST /members/2       (o)

삐삐- 새로운 데이터를 등록할 때는 POST 메소드 사용. insert 는 내가 등록하겠다라는 행위이기 때문에 URI 에 들어가서는 안됨. 오답!

음음 밑에껀 깔끔하구만.

 

https://meetup.toast.com/posts/92

REST API 제대로 알고 사용하기 : NHN Cloud Meetup

 

역시나도나 멋찐분의 글을 보고 정리했다 .. 증맬 멋지신분 더 자세한 내용들도 여기 보면 아아 이런것이 RESTful 하다... 라고 느끼실 수 있을 것.

 

 

이러한 중심규칙으로 좀 더 CRUD 에 대한 자세한 REST API 예시도 정리.

 

종류	기능
POST /posts	글 작성
GET /posts	포스트 목록 조회
GET /posts/:id	특정 포스트 조회
DELETE /posts/:id	특정 포스트 삭제
PATCH /posts/:id	특정 포스트 업데이트  ( 구현 방식에 따라 PUT 으로 사용 가능)
POST /posts/:id/comments	특정 포스트의 댓글 등록
GET /posts/:id/comments	특정 포스트의 댓글 목록 조회
DELETE /posts/:id/comments:commentId	특정 포스트의 특정 댓글 삭제

 

이거슨.....장고를 하면서 보았던.......... 어떻게 보면 개념적인 부분으로 다시 회귀했군 끌끌 하지만 그 때는 무작정 썼으니 지금은 좀 더 아아 이런것들이 규칙이라 나는 POST 를 썼고 GET 을 썼구나! 라는 것을 느끼는 중 음음

 

---

 

 

오늘은 생각보다 일찍 끝났지만 항상 혼자 검색하고 아~ 하고 넘어갔던 부분을 정리할 때가 온 것 같아서 한 번 주우욱 정리해보았다. 

단순히 postman 을 그냥 처음 했을 때 api 요청이 뭔지부터 감을 못잡고 뭐야 무슨말이지..? 라고 생각했는데, 주욱 훑으니까 아아아 그래서 요청을 보내면 응답을 아아아아 하면서 왜 하는지도 알게 되고 하면서 아아 이런 요청을 할 때 rest api 를ㄹ 아아아아 하면서... 오늘도 역시 타고타고 들어가서 개연성은 드릅게 없지만 나름 개운한 포스팅이었움. 키키 오늘은 끝!