URI 설계

• URI설계는 바로 리소스 식별이다.
  이 리소스 식별이 뭘까?

리소스

• 리소스는 어떠한 행위, 동작이 아닌 개념이다.
  예를들어 회원을 "등록, 수정, 조회"하는게 리소스가 아니라
  "회원"이라는 개념이 리소스이다.

• 그럼 이 "회원" 리소스를 식별하여 URI에 매핑하면 된다.

• 그리고 이 리소스와 행위를 분리해야한다.

  • URI는 리소스만 식별하고 URI는 행위를 판별하는데 쓰이면 안 된다.
  • 그럼 이 행위는 어떻게 판별하느냐? -> HTTP method가 이를 대신한다.

HTTP method

GET:

• Representation 조회
• query-string(query-param)으로 조회
• body는 최신 스팩에는 "막지 않는다" 라고 명시되어있긴 하나 convention하게 사용하지 않음.
• 캐싱을 함.

POST:

• 요청 데이터 처리, 처리 방법은 정해진 것이 없기 때문에 리소스마다 정의해줘야함.
  이는 리소스 생성이 될 수 있고, 데이터를 갖고 프로세스를 처리할 수도 있다.
  
• 응답을 보낼 때 생성되었다면 201로 보낸다.
  그리고 함께 location이라고 자원이 생성된 URI 경로도 등록된 자원과 함께 보내준다.
• 그리고 앞서 행위는 URI에 넣으면 안 된다고 하였는데 실무에서는 항상이라는 법은 없기에 control URI 라고 해서 정말 어쩔 수 없이
  POST /orders/{orderId}/start-delivery 이런식으로 작성될 수도 있다.
  그래서 이런 control URI도 post로 처리한다.
• 물론 조회는 GET으로 요청하지만 파라미터가 너무 길거나 2,3 차원 파라미터라 JSON으로 처리해야하는 경우, POST 메서드로 body에 담아서 넘기면 된다.
• 캐싱하기 매우 어려움.

PUT:

• Representation "완전히" 대체, 없다면 생성 즉, 덮어씌우기
• Post와 Put의 가장 큰 차이점은 클라이언트가 path를 알고있냐 모르냐의 차이이다.

PATCH:

• Representation 부분 변경
• 만약 PUT처럼 완전히 덮어씌우는게 아니라 부분만 변경하려면 PATCH를 쓰면 됨.
• 가끔 PATCH를 지원하지 않는 서버들이 있는데 이땐 POST를 쓰면 됨.

DELETE:

• Representation 삭제

HEAD:

• GET과 동일하지만 메시지 부분을 제외하고, 상태줄과 헤더만 반환

OPTIONS:

• 대상 Representation에 대한 통신 가능 옵션을 설명 (CORS에서 주로 사용)

CONNECT:

• 대상 자원으로 식별되는 서버에 대한 터널을 설정

TRACE:

• 대상 Representation에 대한 경로를 따라 메시지 루프백 테스트를 수행

HTTP method 속성

안전 (Safe Methods)

• 여러번 호출해도 리소스를 변경하지 않는걸 안전하다고 한다.

• 당연 값을 바꾸는 다른 HTTP method들은 safe하지 않는다고 나와있다.

• 그럼 GET을 무한대 호출해서 로그가 많이 쌓여 서버에 장애가 발생하면 안전하지 않은거 아닌가? -> 여기서 "안전"이라는 개념은 리소스의 변경에만 해당하는 말이지 서버의 안전까지 고려하는 부분은 아니다.

멱등 (Idempotent Methods)

• f(f(x)) = f(x)
  아이덴포텐트 즉, 여러번 호출하여도 한 번 호출한 것 거처럼 "행위"결과가 같다는 것이다.

• 그럼 POST나 PATCH 처럼 특정 값을 바꾸는 메서드들은 당연 결과가 다를 수 있기 때문에 멱등하지 않는다.
  예를들어 2번 결제하면 2번 결제가 되어버린다. 즉, 함수를 2번 호출하면 1번 호출한 것과 같은 결과가 나오는게 아니다는 것이다.

• 그러나 PUT과 DELETE는 멱등하다. 왜일까? -> 정확히 말하면 "행위의 결과"가 같다고 볼 수 있기 때문이다.
  PUT은 항상 값을 갈아치우는 결과를 받고
  DELETE는 항상 값을 삭제하는 결과를 받기 때문이다.

멱등의 활용

• 자동 복구 메커니즘
  • 서버가 TimeOUT으로 정상 응답을 못 주었을 떄, 클라이언트가 같은 요청을 다시해도 되는가?의 판단 근거가 된다.

캐시가능 (Cacheable Methods)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능
  • 실제로는 GET, HEAD 정도만 캐시로 사용, URL만 캐시 키로 잡고 사용하기만 하면 되서 편함
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음