All ContentsCategoryAbout

좋은 URI(Uniform Resource Identifier) 설계

28 May, 2021 - Network - 2 min read

좋은 URI(Uniform Resource Identifier) 설계

리소스?

  • 예를 들어 ‘회원정보조회 API’가 있다면, ‘회원’이라는 개념 자체가 바로 리소스

리소스를 어떻게 식별해야 할까

  • 등록, 조회, 수정 등은 배제하고 오로지 ‘회원’이라는 리소스만 식별하면 된다. 회원 리소스를 URI에 매핑하는 것이다.
  • URI리소스만 식별하며, 리소스의 행위(ex: 조회, 등록, 삭제, 수정)를 포함하면 안 된다.
  • 행위는 HTTP method를 통해 식별한다.
  • GET, POST, PUT, PATCH, DELETE

URI 설계의 예외상황

  • 리소스만으로 URI를 설계하면 가장 이상적이나 현실적인 한계가 있다. 이럴 때는 예외적으로 URI에 동사가 포함된 ‘컨트롤 URI’를 설계하기도 한다.

POST의 다양한 쓰임새

  • POST단순히 새로운 정보 등록에만 쓰이지 않는다.
  • JSON 형태의 body를 가질 수 있게 때문에 GET으로 처리할 수 없는 다양한 문제들에 쓰일 수 있다.
  • ex) [결제완료 -> 배달시작 -> 배달완료]와 같이 단순한 값 추가, 변경을 넘어 프로세스의 상태가 변경되는 경우

PUT과 POST의 차이

  • PUT은 이미 존재하는 리소스를 대체하며, 리소스가 없을 경우 생성한다.
  • 클라이언트에서 해당 리소스의 path를 알고 있을 때 사용한다. - ex) /members/10

PUT과 PATCH의 차이

  • PUT은 리소스 전체를 대체하기 때문에 전송하지 않은 필드는 사라지며, 부분 변경에는 PATCH를 쓴다.
  • ex) 아래와 같은 원본 데이터가 있을 때
{
  "name": "sooyoung",
  "age": 34,
  "gender": "male"
}
  • PUT으로 이름만 {"name": "intzero"} 전송했을 경우 해당 리소스는 아래와 같이 업데이트된다.
{
  "name": "intzero",
  "age": null,
  "gender": null
}
  • PATCH로 동일하게 이름만 전송했을 때에는 아래와 같이 업데이트된다.
{
  "name": "intzero",
  "age": 34,
  "gender": "male"
}

© 2023 intzzzero, Built with

Gatsby