HTTP-method 종류와 특징, 속성

1. API URI 설계

API URI 설계 시 가장 중요한 것은 리소스 식별 이다.

회원 목록 조회 /read-member-list
회원 등록 /create-member
회원 수정 /update-member
회원 삭제 /remove-member

위와 같은 URI에는 회원이라는 리소스를 식별하는데 집중하기보다는, 어떤 일을 수행하는가에 집중되어 있는 URI이다. 이는 올바른 URI 설계가 아니다.

회원 목록 조회 /members
회원 등록 /members/:id
회원 수정 /members/:id
회원 삭제 /members/:id

이처럼 URI는 리소스 자체를 식별하는 하는데 집중하는 것이 좋다. 즉 리소스와 해당 리소스를 대상으로 하는 행위를 분리 시키는 것이 좋은 URI 설계라 할 수 있다. 그럼 행위는 어떻게 지정할까?

바로 HTTP-method를 통해 해결할수 있다

2. HTTP-method

1. GET

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

2. POST

• 메시지 바디를 통해 서버로 요청 데이터를 전달한다. 서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
  • 신규 리소스를 성공적으로 등록 한 경우, 201 status code와 Location(URI 경로)를 보내준다.
  • 프로세스 처리 시 POST의 결과로 새로운 리소스가 생성되지 않을 수 있다.
• 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지에 대해서는 정해져 있지 않으므로 리소스마다 따로 정해야 한다.
• 다른 메소드로 처리하기 애매한 경우 POST 요청으로 처리할 수 있다. 다만 조회 같은 경우 POST 사용 시 캐싱이 어려우므로 GET 사용을 권장.

3. PUT

해당 URI에 리소스가 있다면 요청 시 담겨진 리소스로 대체하거나, 리소스가 없다면 요청 시 담겨진 리소스로 새롭게 생성한다. 즉 덮어쓰기라고 생각하면 쉽다.

• POST는 클라이언트가 리소스의 위치를 알지 못한다.
  • 리소스가 생성 된 후 서버에서 Location을 보내준다.
  • 때문에 , 클라이언트에서 리소스의 위치를 URI로 지정하지 못한다.
• PUT은 클라이언트가 리소스 위치를 알고 있기 때문에, URI로 리소스 위치를 지정해 요청을 보낸다.

4. PATCH, DELETE

• PATCH는 리소스를 부분적으로 변경한다.
  • 지원하지 않는 경우도 있는데, 그런 경우 POST를 사용한다.
  • 개인적으로 알아봐야 할 부분
    프로젝트에서 리소스를 부분적으로 변경할 때, PUT을 사용한 경험이 있다. PUT을 사용하여도 부분적으로 리소스 변경이 되었었는데.... 정확하게 어떤 method를 사용해야 하는 건지 알아봐야겠다.
• DELETE는 URI에 해당하는 리소스 삭제 요청 시 사용한다.

5. 기타 메서드 종류

• HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설정(주로 CORS에서 사용)
• CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

3. HTTP-method 속성

안전 (Safe methods)

계속해서 호출해도 리소스를 변경하지 않는 특성.
만약 계속된 호출로 인해, 로그가 쌓여 장애가 발생한다 하여도, 이런 부분까지는 고려하지 않는다. 안전은 해당 리소스만이 고려 대상이다.

멱등 (Idempotent methods)

동일한 요청을 계속해서 보내도 결과는 동일해야 한다.
외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려 대상이 아니다.
GET, PUT, DELETE는 멱등성을 가지도록 구현해야 한다.
POST는 멱등이 아니다. 예를 들어 POST 요청 시 결제가 이루어진다면, 두 번 호출 시 중복 결제가 발생할 수 있다.

캐시가능(Cacheable Methods)

응답 결과로 받은 리소스를 캐시 해서 사용해도 되는지에 대한 속성.
GET, HEAD, POST, PATCH는 캐시가 가능한 methods, 하지만 실무에서는 구현이 쉽지 않아 GET, HEAD 정도만 캐시 가능 methods로 사용.

Reference

모든 개발자를 위한 HTTP 웹 기본 지식