이 포스트는 김영한님의 ‘모든 개발자를 위한 HTTP 웹 기본 지식’을 수강하고 작성하였습니다.

API URI 설계

회원 조회면 select문을 쓸테니 select-member, 등록이면 insert니까 insert-member… 이거 아니야?

API URI를 설계하는 데 있어서 가장 중요한 것은 리소스 식별이다.
그렇다면 리소스의 의미는 무엇일까?
바로 회원을 조회하고 등록하고 수정하는 것이 아니라, 회원이라는 개념 자체가 리소스다.

즉, 회원이라는 리소스만 식별하면 되므로, 회원 리소스를 URI에 매핑한다. 뭔가 동작의 주체가 되는 것을 기준으로 하는 것 같다.

probe
예) 프로브가 미네랄을 캔다. 여기서의 리소스는 프로브다. 그리고 귀엽다.

만약 프로브를 관리하는 API를 만든다고 치면

  • 프로브 자원 채취 - /probes/{no}
  • 프로브 탐사 - /probes/{no}
  • 프로브 건물 짓기 - /probes/{no}
  • 프로브 공격하기 - /probes/{no} 정도가 될 것이다. (참고로 계층 구조 상 상위를 컬렉션으로 보고 복수 단어 사용을 권장한다.)

그런데 여기서 문제점이 있다. 저렇게 해 놓으면 몇 번 프로브에 해당하는 작업인지는 알지만, 그 프로브가 자원을 채취하는 건지, 탐사를 나가는 건지에 대해서는 구분할 수 없다.
그걸 해결하는 것이 HTTP 메서드이다. 아직 학습은 안 했는데 대강 감을 잡자면 GET으로 쿼리 스트링 보내는 거 아닐까 싶다.

리소스와 행위를 분리한다.

API URI 설계에서 가장 중요한 것은 리소스를 식별하는 것이다.

  • URI는 리소스만 식별한다.
  • 리소스와 해당 리소스를 대상으로 하는 행위를 분리한다.
    • 리소스: 프로브
    • 행위: 자원 채취, 탐사, 건물 짓기, 공격하기
  • 리소스는 명사, 행위는 동사
    • 예) 프로브(리소스)가 수정탑을 짓는다(행위).
  • 행위를 구분하기 위해 HTTP 메서드를 사용한다.

댓글남기기