HTTP 메서드 종류 및 좋은 API URI 설계

회원 정보 관리 API를 아래와 같이 만든다고 가정해보자.
- 회원 목록 조회
- 회원 조회
- 회원 등록
- 회원 수정
- 회원 삭제

API URI 설계 - URI(Uniform Resource Identifier)
- 회원 목록 조회 /read-member-list
- 회원 조회 /read-member-by-id
- 회원 등록 /crate-member
- 회원 수정 /update-member
- 회원 삭제 /delete-member

위 설계는 좋은 URI 설계일까?
설계에서 가장 중요한 것은 리소스 식별!!

API URI 고민

- 리소스의 의미는? 회원을 등록하고 수정하고 조회하는게 리소스가 아니다. 회원이라는 개념 자체가 바로 리소스이다.
- 리소스를 어떻게 식별하는게 좋을까? 회원을 등록하고 수정하고 조회하는 것을 모두 배제하고 회원이라는 리소스만 식별하면 된다. 즉, 회원 리소스를 URI에 매핑한다.

API URI 설계 - URI(Uniform Resource Identifier)
- 회원 목록 조회 /members
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}
* 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용을 권장한다. (member > members)

위 설계처럼 변경했을 때, 회원 조회/등록/수정/삭제 URI 가 모두 같다.
그렇다면, 어떻게 구분할것인가?

리소스와 행위를 분리!
가장 중요한 것은 리소스를 식별하는 것!

URI는 리소스만 식별하고, 리소스를 대상으로 하는 행위를 분리한다.
- 리소스 : 회원
- 행위 : 조회, 등록, 삭제, 변경
즉, 리소스는 명사를 행위는 동사를 나타낸다. 
행위를 구분하기 위해서 HTTP 메서드를 이용한다.

HTTP 메서드 종류

주요 메서드

GET	리소스 조회
POST	요청 데이터 처리, 주로 등록에 사용
PUT	리소스를 대체, 해당 리소스가 없으면 생성
PATCH	리소스 부분 변경
DELETE	리소스 삭제

기타 메서드 

HEAD	GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS	대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT	대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE	대상 리소스에 대한 경로를 따라 메시지 루프백 테스를 수행

 

GET

- 리소스 조회
- 서버에 전달하고 싶은 데이터를 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
- 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음.

POST

- 요청 데이터 처리
- 메시지 바디를 통해 서버로 요청 데이터 전달
- 서버는 요청 데이터를 처리
(메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.)
- 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용한다.

!! 요청 데이터를 처리?
POST는 다음과 같은 기능에 사용된다.
- HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용(HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공)
- 게시판 글쓰기, 댓글 달기 등 (게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시(
- 신규 주문 생성 등 (서버가 아직 식별하지 않은 새 리소스 생성)
- 한 문서 끝에 내용 추가하기 (기존 자원에 데이터 추가)

>>> 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다. 즉, 정해진 것이 없다.

!! POST 정리

- 새 리소스 생성(등록) : 서버가 아직 식별하지 않은 새 리소스 생성
- 요청 데이터 처리 : 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우 / POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음.
- 다른 메서드로 처리하기 애매한 경우 : 예를 들어 JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우. 결론은 애매할 땐 막강 슈퍼 메서드가 POST 임.

PUT

- 리소스를 대체 : 리소스가 있으면 대체, 없으면 생성. 즉, 파일이 없는 경우 생성하고 파일이 있는 경우는 덮어씌어버리는 개념
- 클라이언트가 리소스를 식별 : 클라이언트가 리소스 위치를 알고 URI 지정

!! 주의할 점
리소스를 완전히 대체한다.
{
username: tion
age: 20
}
위 데이터가 서버에 저장되어 있을 때, 
{
age : 50
}
으로 처리하면 username 필드는 삭제되고 age만 남게 된다.
즉, 부분적으로 대체하는게 아닌, 기존 데이터를 날리고 새로운 데이터를 덮어씌우는 개념으로 봐야한다.

PATCH

- 리소스를 부분 변경한다.
{
username: tion
age: 20
}
위 데이터가 서버에 저장되어 있을 때, 
{
age : 50
}
으로 처리하면,
{
username: tion
age: 50
}
으로 age만 부분 변경된다.

DELETE

- 리소스를 제거한다.