이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
신입 개발자가 첫 API 설계를 맞는 임무에 투입됐다고 가정해보자!!
아래와 같은 요구 사항이 있다면, 아마 가장 먼저 드는 생각은 이름을 잘 지어서 구별하자는 것일 것이다.
딱 봐도, 한 눈에 URI들이 어떤 역할을 하는지 알 수 있다.
회원 목록 조회 => /read-member-list
그러나, 이게 정말 좋은 URI일까??
실제로 현업에서 이런 식으로 설계를 많이한다고 한다!!
그런데, URI를 설계할 때 가장 중요한 것은 "리소스" 식별이다!!
리소스??
최근에는 "Representation" 이라는 이름으로 바뀌었다.
ex)
"밥을 먹자!!" => "밥"이 리소스이다. "먹자!"는 리소스가 아니다.
위의 API 설계에서는 "회원 조회"라고 하면, "회원"만이 리소스이다.
그래서 "리소스"를 어떻게 식별하라고??
"회원"이라는 리소스만 식별하자!! => "회원" 리소스를 URI에 매핑!!
그래서, 권장한 방법대로 리소스만을 식별해서 members까지 했다.
회원 조회까지는 그럭저럭 해냈지만, 그 외에 "등록", "수정", "삭제"는 members라는 리소스만 가지고는 표현하기가 어렵다.
이 문제를 어떻게 해결해야 할까??
HTTP 메소드
URI는 "리소스"를 판별하는데 써야한다!!
리소스의 행위를 판별하는데 쓰면 안 된다.
그럼 이 행위!! "등록", "수정", "삭제" 등은 HTTP 메소드를 통해서 구별한다.
HTTP 메서드는 "클라이언트가 서버에 요청할 때, 기대하는 행동"이다.
URI 설계 예외 - 컨트롤 URI
URI는 리소스 단위로 설계해야 한다.
그런데, 위와 같이 어쩔 수 없이 "리소스"만으로 안 될 때가 있다.
그럴 때는 위와 같이 설계하기도 한다.
start-delivery 같이 동사적인 URI가 나올 수 있다.
이런 URI를 " 컨트롤 URI "라고 부른다.
실무에서는 "리소스"만을 가지고 URI를 다 설계할 수는 없다.
기본적으로 "리소스"로 최대한 URI를 설계하되, 어쩔 수없는 것는 부분들은 컨트롤 URI라는 걸로 설계해야한다.
URI 설계에서 중괄호 의미
