HTTP 메서드

인프런 '모든 개발자를 위한 HTTP 웹 기본지식' 강의를 듣고 정리했습니다. 자세한 내용을 알고싶으면 해당 강의를 듣는 것을 추천드립니다.

 

API URI 설계에 관한 내용을 알아보록 하자.

 

회원 목록 조회 / read-member-list

회원 조회 /read-member-by-id

회원 등록 /create-member

회원 수정 /update-member

회원 삭제 /delete-member

 

나는 실제로 업무에서 이런식으로 uri를 설계했다.

이게 정말 좋은 uri 설계인지 생각해봐야한다. 

가장 중요한 것은 리소스별 식별이 필요하다. 

 

 

리소스란 무었일까?

- 미네랄을 캐라 --> 미네랄이 리소스이다. 

- 회원이라는 개념 자체가 바로 리소스이다. 

 

 

리소스를 어떻게 식별하는게 좋을까?

- 회원을 등록하고 수정하고 조회하는 것은 모두 배제

- 회원이라는 리소스만 식별하면 된다. --> 회원 리소스를 uri에 매핑

 

회원 목록 조회 /members

회원 조회 /members/{id}

회원 등록 /members/{id}

회원 수정 /members/{id}

회원 삭제 /members/{id}

 

리소스와 행위를 분리

- uri는 리소스만 식별

- 리소스와 해당 리소스를 대상으로 하는 행위를 분리

- 리소스 : 회원

- 행위 : 조회, 등록, 삭제, 변경

- 리소스는 명사, 행위는 동사

- 행위(메서드)는 어떻게 구분? 

 

 

HTTP 메서드 종류

- GET : 리소스 조회

- POST : 요청 데이터 처리, 주로 등록에 사용

- PUT : 리소스를 대체, 해당 리소스가 없으면 생성

- PATCH : 리소스 부분 변경

- DELETE : 리소스 삭제

- HEAD : GET과 동일, 메시지 부분을 제외하고 상태 줄과 헤더만 변환

 

 

GET 

- 리소스 조회

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

- 메세지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않는다.

 

 

POST

- 요청 데이터 처리

- 메시지 바디를 통해 서버로 요청 데이터 전달

- 서버는 요청 데이터를 처리

- 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행

- 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

- 애매하면 POST를 사용한다. 

 

 

PUT

- 리소스 대체 (있으면 대체 없으면 생성)

- 클라이언트가 리소스를 식별 (클라이언트가 리소스 위치를 알고 uri지정)

 

 

PATCH

- 리소스 부분을 변경

 

 

DELETE

- 리소스 제거