HTTP API

HTTP API URI 설계

• 리소스를 중점으로 설계해야함
  • 리소스 : 자원
    • 리소스와 행위를 분리
  • HOW?) HTTP 메서드 - GET, POST

HTTP 메서드 종류

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용(즉, 데이터를 줄테니까 처리해줘란 의미)
  • post 메서드의 고유한 의미체계(게시판 글쓰기, 댓글 달기, 회원가입, 주문 등)에 따라 표현을 처리해달라고 요청한다.
  • 이렇게 보내진 post 데이터를 어떻게 처리할지 리소스(URI)마다 따로 정해야함(정해진것이 없음)
  • 최대한 리소스를 기준으로 URI를 설계하는것이 바람직하지만, 여건이 안될 때는 컨트롤 URI를 사용한다.
    • 컨트롤 URI 예시) POST /orders/{orderId}/start-delivery
  • 다른 메서드로 처리하기 애매할 경우 POST 사용
• PUT : 리소스를 완전히 대체, 해당 리소스가 없으면 생성
  • POST와 달리 클라이언트가 URI 리소스를 식별
  • 완전히 대체의 의미는 예를 들어 username과 age 두개의 필드가 있는데, PUT을 이용해 age값을 변경하면 username 필드가 완전히 날라가버리는것을 의미한다.
• PATCH : 리소스 부분 변경
  • 완전한 대체자인 PUT의 완화버전
  • PATCH를 지원하지 않는 서버는 POST를 사용하면된다.
• DELETE : 리소스 삭제

HTTP 메서드의 속성

• safe : GET
  • non-safe : post,put,delete
• Idempotent(멱등) : 한번 호출하든 100번 호출하든 결과가 똑같다.(GET,DELETE,PUT)
  • non-idempontent : POST(같은 결제가 중복해서 발생할 수 있다.)
  • 자동 복구 메커니즘(서버에서 요청 결과가 오지 않았을 때 한번더 요청 가능)
• 캐시가능 : 응답 결과 리소스를 캐시해서 사용 가능한가?
  • 캐시가능 : (GET, HEAD, POST, PATCH)
  • 실제로는 GET, HEAD 정도만 캐시로 사용
    • POST, PATCH는 본문 내용까지 캐시키로 고려해야하는데 구현이 쉽지 않음