[HTTP] API URI 설계

📌URI 설계

URI 설계시 가장 중요하게 생각할 것은 '리소스' 식별 이다

그렇다면 리소스의 의미는 무엇일까?

회원을 예시로 들자면 회원을 등혹하고 수정, 조회하는것이 리소스가 아니라
회원이라는 개념 자체가 리소스라고 할 수 있습니다 :)
리소스에 대한 개념을 확실하게 이해하고 식별 후 URI 설계를 해야합니다

그렇다면 리소스를 어떻게 식별해야 할까?

회원을 예시로 회원을 등록하고 수정하고 조회하는 것을 모두 배제한 후
회원이라는 리소스만 식별 해야 합니다.
(회원 리소스를 URI에 매핑)

리소스와 행위를 분리 ( 가장 중요한 것은 리소스를 식별 하는 것 )

리소스와 해당 리소스를 대상으로 하는 행위를 분리하여야 합니다!
행위는 http 메소드를 이용하여 구분 합니다

URI 설계 예)

• 회원목록조회 GET / members
• 회원조회 GET / members/{id}
• 회원등록 POST / members/{id}
• 회원수정 PATCH / members/{id}
• 회원삭제 DELETE / members/{id}
• 참고: 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용을 권장합니다 ( member -> members)

---

📌 HTTP 메서드 종류

GET

• 일반적으로 리소스 조회시 사용합니다.
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달 합니다.
• 메시지 바디를 사용해서 데이터를 전달 할 수 있지만, 지원하지 않은 곳이 많으므로 권장하지 않습니다.

POST

• 일반적으로 요청 데이터 처리시 사용합니다.
• 메세지 바디를 통해 서버로 요청 데이터를 전달 합니다.
• 서버는 요청 데이터를 처리합니다.
  (메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행)
• 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리시 사용 됩니다.
• 다른 메서드로 처리하기 애매한 경우에도 사용 된다.
  ( 예로 JSON으로 조회 데이터를 넘겨야 하는데 GET 메서드를 사용하기 어려운 경우 )

PUT

• 리소스를 '완전히' 대체시 사용 합니다.
  ( 리소스가 있으면 대체, 리소스가 없으면 생성 합니다 (덮어쓰기로 이해하면 편함!) )
• 클라이언트가 리소스를 식별 합니다.
  ( 클라이언트가 리소스 위치를 알고 URI를 지정합니다 (POST와의 차이점) )

PATCH

• 리소스를 '부분' 변경시 사용합니다.
  ( PUT의 경우 기존의 리소스를 '완전' 대체 하므로 리소스의 특정 부분변경 원할경우 사용합니다 )
• PUT과 마찬가지로 클라이언트가 리소스를 식별 합니다.

DELETE

• 리소스를 제거시 사용합니다.
• 클라이언트가 PUT, PATCH와 마찬가지로 특정 리소스를 식별 합니다.

• 이외의 여러가지 메서드가 있지만 이번 포스팅에선 위의 대표적인 메서드만 다뤄 보았습니다 :)

---