URI 설계

좋은 URI 설계란 무엇인가?

좋은 URI를 설계하기 위한 가장 중요한 점은 리소스를 식별이다

그렇다면 리소스란 뭘까

회원 명부를 예시로 든다면,
회원을 등록, 수정, 조회, 삭제 등이 있을때
회원을 리소스, 등록, 수정 등을 메소드라고 할 수 있다

그렇다면 리소스는 어떻게 식별하도록 하는게 좋은 URI 설계일까?
-> 메소드를 배제하고, 오직 리소스만을 식별할 수 있도록 만들어야 한다

리소스를 식별할 수 있는 수단인 메서드에 대해서 알아보자

HTTP 메서드의 종류

1. GET - 리소스 조회
2. POST - 요청 데이터 처리 ex) 등록
3. PUT - 리소스를 대체하며 없을경우 생성한다
4. PATCH - 리소스 부분 변경
5. DELETE - 리소스 삭제

---

6. HEAD - 상태줄과 헤더만 조회
7. OPTIONS - 통신 가능 메소드를 설명
8. CONNECT - 서버에 대한 터널 설정
9. TRACE - 메시지 루프백 테스트 수행

GET

• 리소스를 조회
• 서버에 전달하고 싶은 데이터는 query를 통해 전달
• 메세지 바디를 통해 데이터 전달이 가능하지만, 지원 하지않는 경우가 많아 X

  요청
  GET /numbers/100 HTTP/1.1
  Host: localhost:8080
  ->
  /numbers/100
  { username : XX, age : OO }

  응답
  HTTP/1.1 200 OK
  Content Type:
  Content Length
  { username : XX, age : 00 }

Post

• 요청 데이터 처리
• 메시지 바디를 통해 서버로 데이터 전달
• 서버는 요청 데이터를 처리함
• 주로 신규 리소스 등록에 사용

  요청
  Post /members HTTP/1.1
  Content-Type
  { username : XX, age : 00 }

  -> /members/OOO 신규 리소스 식별자 임의의 위치에 생성

  응답
  HTTP/1.1 200 OK
  Content Type:
  Content Length
  Location : /members/OOO << 생성 경로 제공
  { username : XX, age : 00 }

사용처

1. 새 리소스 생성

• 서버에 아직 존재하지 않는 신규 리소스 생성

2. 요청 데이터 처리

• 프로세스의 상태가 변경되는 경우
  ex) 주문 -> 결제완료 -> 배달시작 -> 배달완료
  POST /orders/{orderID}/start-delivery
  POST /orders/{orderID}/complete-delivery

---

PUT

메시지 바디에서 모든 필드 값이 아닌 일부만 있다면 그 외의 필드값은 삭제하며 메시지 바디 내의 필드값으로 재생성

쉽게 말해 덮어쓰기

PUT /members/100 HTTP/1.1

POST는 서버가 위치를 관리하는 것과 다르게 PUT의 경우 위 처럼 _클라이언트가 리소스 위치를 인지하는 상태에서 URI(members/100)을 지정해야함

PATCH

리소스의 부분 변경

메시지에 모든 필드 값이 아닌 일부만 있다면 그에 해당하는 일부만 값을 변경

DELETE

리소스 삭제