HTTP 메서드

백앤드 개발을 하다 보면 API를 설계할 경우가 있다. 나도 과거에 API URI를 설계했던 적이 있었다. 

그 당시 나는 URI 설계 방법에 대해서 하나도 몰랐다. 그래서 강의 처음에 나온 예시처럼

회원 목록 조회 /read-member-list
회원 조회 /read-member-by-id
회원 등록 /create-member
회원 수정 /update-membe
회원 삭제 /delete-member

이런 식으로 URI를 설계했던 적이 있었다. 

그럼 좋은 URI를 설계하는 방법은 무엇일까?

 

API URI 설계

URI를 설계할 때 가장 중요한 것은 리소스 식별이다. 

그럼 리소스는 무엇일까? 나는 리소스는 주어라고 생각한다. 

위에 예시에서 회원 목록을 조회하고, 저장하고 하는 것에서 회원이라는 개념 자체가 바로 리소스이다. 

조회하고, 저장하고.. 는 HTTP 메서드를 이용해서 판별할 수 있다. 

리소스와 행위를 분리!

• URI는 리소스만 식별한다. 
• 리소스는 명사, 행위는 동사
• 행위는 HTTP 메서드를 이용해서 구분

 

HTTP 메서드

HTTP에 주요 메서드들만 설명하겠다. 

GET

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query를 통해 전달
• message body를 사용할 수 있지만 지원하지 않는 서버가 있어서 권장하지 않음

POST

• 요청 데이터를 처리 
• 애매하면 다 POST
• message body를 사용해서 서버에 데이터 전달

PUT

• 리소스를 대체할 때 사용
• 클라이언트가 리소스를 알고 URI를 지정한다. (POST와의 차이점)
• 리소스를 완전히 대체한다.

PATCH

• 부분적으로 리소스를 변경할 때 사용

DELETE

• 리소스를 삭제

 

HTTP 메서드의 속성

안전

• 호출해도 리소스를 변경하지 않는다. 

멱등(Idempotent)

• 한번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
• 멱등 메서드
  • GET
  • PUT
  • DELETE
• 자동 복구 메커니즘에 활용된다. 

캐시 가능

• 응답 결과 리소스를 캐시 해서 사용할 수 있는가?
• GET, HEAD, POST, PATCH 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시로 사용한다. 

출처: HTTP - 위키백과, 우리 모두의 백과사전 (wikipedia.org)