HTTP API 설계

요구사항

회원 목록 조회
회원 조회
회원 등록
회원 수정
회원 삭제

URI의 기능

URI는 리소스를 식별만 해야한다.

리소스와 해당 리소스를 대상으로 하는 행위를 분리해야한다.

HTTP 메서드

GET

리소스 조화
서버에 전달하기 원하는 데이터는 query를 통해서 전달한다.
get으로 메세지 바디를 보낼 수는 있지만, 안되는곳도 많다

POST

요청 데이터 처리, 주로 등록에 사용
서버에 정보를 주면, 서버가 그 정보를 받아서 처리한다.

어떻게 처리한다는것일까?

예시

• HTML FORM에 입력한 정보로 회원가입, 주문 등에 사용
• 게시판에 글을 쓰거다 댓글을 단다
• 서버가 식별하지 않은 새 리소스 (주문) 생성
• 기존 자원에 데이터 추가

1. 새 리소스 등록
2. 데이터 처리
   • 프로세스가 처리가 되는 단계 (결제 - 배송 - 완료)에서도 POST를 쓴다.
     따라서 꼭 POST를 쓴다고 리소스가 생기는건 아니다.
     POST로 리소스만 가지고 URI를 설계할 수가 없어서 CONTROL URI도 씀
3. 다른 메소드로 처리하기 애매하면 POST를 쓴다.

PUT

리소스를 대체, 없으면 생성
LINUX의 NANO같은 기능
있으면 완전하게 교체하고 없으면 만든다.

클라이언트가 리소스를 정확히 지정을 한다. 이 부분이 POST와 다르다.

PATCH

리소스 부분 변경
PUT과 같은 기능인데 부분변경을 한다.

DELETE

리소스 삭제
정확히 리소스를 잡아주면 그 리소스를 삭제한다.

기타

HEAD

GET와 유사하지만, 상태와 헤더만 반환

OPTION

대상 리소스에 대한 통신 가능 옵션을 설명

CONNECT

서버에 대한 터널 설정 (잘 안씀)

TRACE

경로 따라서 루프백 테스트 (잘 안씀)

메서드 속성

출처

안전

호출해도 리소스가 변하지 않는다.
Q. 계속 호출하면 로그가 쌓여서 장애가 발생하지않는지?
A. 그건 몰?루

멱등 (Idmepotent)

N번 호출해도 결과가 똑같아야한다.
GET : 100번 조회하든 1000번 조회하든 결과가 똑같다.
PUT : 결과를 대체한다. 따라서 몇번을 호출해도 똑같다.
DELETE : 삭제하니깐 몇번을 해도 삭제된다.
POST : 두 번 호출하면 결과가 변할 수도 있다. (프로세스 처리의 경우)

이 멱등은 자동 복구 메커니즘에서 사용한다.
DELETE가 오류가 나면 자동으로 재시도.

Q. 재요청 중간에 리소스가 변하면?
A. 외부요인으로 리소스 변하는건 신경쓰지 않느낟.

캐시가능

응답 결과 리소스를 캐시로 사용해도 되는가?

GET, HEAD, POST, PATCH는 해도 된다
실제로는 GET, HEAD 같은 단순조회만 하고 POST PATCH는 구현하기가 어렵다.