HTTP 메서드

HTTP API

API를 만든다고 가정해보겠습니다.

• 게시글 목록 조회 /posts-list
• 게시글 단일 조회 /posts-by-id
• 게시글 등록 /create-posts
• 게시글 수정 /update-posts
• 게시글 삭제 /delete-posts

위 기능들의 uri가 과연 좋은 uri설계일까요?uri설계에서 가장 중요한것은 리소스 식별입니다. 그럼 리소스 식별은 어떻게 하는 걸까요?

• 리소스를 이용하는 행위를 모두 배제합니다.
• 리소스를 식별하기만 하면 된다 > 리소스를 uri에 매핑

uri에서 리소스란?
위 api에서는 게시글이라는 개념을 가지고 조회, 등록, 수정, 삭제라는 행위를 합니다. 행위를 뺀 개념이 바로 리소스입니다. 즉 여기서는 게시글이 리소스입니다. 그러면 리소스 식별을 다시 해본 uri를 보겠습니다.

• 게시글 목록 조회 /posts
• 게시글 단일 조회 /posts/{id}
• 게시글 등록 /posts/{id}
• 게시글 수정 /posts/{id}
• 게시글 삭제 /posts/{id}

뭔가 깔끔해 보이기는 하네요. 근데 여기서 의문이 듭니다. 게시글 목록 조회하는것은 uri가 다르기에 구분이 가능하다지만 나머지는 어떤 행위를 하는지 구분이 되지 않는다는 문제가 발생합니다.

HTTP 메서드의 종류

• GET: 리소스를 조회

  • 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
  • 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지않음

• POST: 요청 데이터를 처리

  • 메세지 바디를 통해서 요청 데이터를 전송
  • 서버는 메세지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 한다.
  • 주로는 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
  • 다른 메서드로 처리하기 어려운 경우에도 사용이 가능
    ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

• PUT: 리소스를 대체

  • 기존의 리소스가 존제한다면 대체 or 없다면 생성 > 즉 파일을 덮어 버린다.
  • 클라이언트가 리소스를 알고 있는 상태여야 하며 URI에 지정해야하는 점에서 POST와 차이점을 가지고 있다.
    ex) 이름 : 길동, 나이 :20 >(이름에 오타가 발생하여 수정) 이름 : 길둥 >(결과) 이름 :길둥 나이는 삭제된다.

• PATCH: 리소스를 부분 변경

• DELETE: 리소스를 제거

HTTP 메서드 특성

안전

몇번을 호출해도 리소스를 변경하지 않는 특성입니다.

Q. 그렇다면 계속해서 호출하여 로그가 쌓이게 되면 장애가 발생하지 않나요?
A. 해당 리소스에 대해서만 고려하지 그러한 부분까지는 고려치 않습니다.

멱등

몇번 호출이되든 같은 결과를 응답하는 특성입니다.

• 멱등 메서드 : GET, PUT, DELETE
  • GET : 한번을 조회하든, 두번을 조회하든 같은 결과를 응답합니다.
  • PUT : 결과를 대체시키는 메서드 > 같은 요청을 여러번 호출해도 최종결과는 같습니다.
  • DELETE : 리소스를 삭제하는 메서드 > 몇번을 삭제하든 삭제라는 최종결과는 같습니다.
• 비멱등 메서드 : POST
  • POST : 예를 들어 결제 호출을 두번하면 중복결제가 됩니다.

Q. 재요청 중간에 다른곳에서 리소스를 변경한다면 결과가 달라지지 않나요?
A. 멱등은 외부요인으로 인해 중간에 리소스가 변경되는것까지는 고려하지 않아요.

캐시가능

• 응답결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH가 캐시가 가능합니다.
• 실제로는 GET, HEAD 정도만 캐시로 사용합니다.
  - POST, PATCH는 바디 내용까지 캐시키로 고려 해야하기에 구현이 어렵습니다.