HTTP 웹 기본 지식 ③ HTTP 메세지 & HTTP 메소드

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

위 강의를 통해 공부한 내용을 정리함

 

 

HTTP 헤더

HTTP 통신에서 모든 데이터는 HTTP 메세지로 담겨서 보내지며 이런 HTTP 메세지는 프로토콜이니 당연히 정해진 규칙이 있음.

 

 

시작 라인 

 

요청시에는 요청 메소드, 요청 대상, HTTP 버전

응답시에는 HTTP 버전, 상태 코드

 

헤더

 

HTTP 전송에 필요한 부가 정보들에 대한 정보! (메세지 바디에 대한 정보, 인증, 압축, 캐시 등등...)

 

메세지 바디

 

말 그대로 주고 받는 메세지 그 자체 

 

 

 

 

이 규칙대로 담고, 이 규칙대로 풀어서 메세지를 주고 받는 것이 HTTP 통신!

 

 

좋은 API URI 설계

좋은 API URI 설계란?

 

가장 중요한 것은 리소스 식별!

 

URL 짤 때 메소드를 기준으로 하면 절대 × 무조건 리소스를 기준으로 해야하고 리소스는 간단하게 설명하면 테이블이라고 할 수 있다.

 

만약에 회원에 대한 API 를 짠다고 가정하면 회원 정보를 가져오고, 수정하고, 삭제하고 이 모든걸 URI 로 나누면 안된다.

여기서 중요한건 회원 그 자체 아마 짜면 /api/members 이런 식으로 짜고 각각의 행위는 HTTP 메서드로 나눠주면 된다.

 

URI 는 이처럼 리소스만 식별하고 행위에 대한 구분은 HTTP 메서드로 해준다.

 

 

 

HTTP 메서드

 

 

GET

리소스 조회

서버에 전달하고 싶은 데이터는 쿼리 파라미터를 통해 전달

※ 메세지 바디를 사용할 수 있긴 하지만 지원을 하지 않는 곳이 많아서 GET 요청시 메세지 바디 쓰는 것은 권장하지 않음

 

POST

리소스 등록

메세지 바디를 통해서 서버로 요청 메세지 전달

다른 메서드들보단 요청이 그렇게 구체적이진 않아서 요청 데이터를 어떻게 처리할지는 리소스마다 다르다.

(→ 만만한게 POST)

 

PUT

리소스 수정 or 생성

리소스가 있으면 수정하고 없으면 생성한다. 쉽게 이야기해서 덮어쓴다.

 

PATCH

리소스 부분 수정

PUT 과 비슷한데 부분 변경한다는 차이가 있다.

 

DELETE

리소스 삭제

 

 

 

HTTP 메서드 속성

안전 → 요청이 리소스에 영향을 끼치는지

멱등 → 요청 한 번 한거랑 요청 여러번 한거랑 응답이 같은지 (외부 요인으로 중간에 리소스가 변한 건 제외)

캐시 가능 → 거의 GET, HEAD 만 캐싱

 

정리하면,