[Network] HTTP Methods

해당 포스팅은 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식 강의를 토대로 작성되었습니다.

 

 

HTTP API 설계

요구사항 및 API URI 설계

예시를 들어 다음과 같은 API 리스트가 있다고 해보자.

1. 회원 목록 조회: /read-member-list
2. 회원 조회: /read-member-by-id
3. 회원 등록: /create-member
4. 회원 수정: /update-member
5. 회원 삭제: /delete-member

 

위의 API 설계는 잘못된 설계이다. 이유는 아래에서 천천히 보자.

API URI 설계 분리

우리는 API URI 설계를 할 때 리소스와 해당 리소스를 대상으로 하는 행위를 분리해야 한다. 위의 예시를 보면 리소스는 회원이고, 행위는 조회, 등록, 수정, 삭제로 정의할 수 있을 것 같다. 따라서 회원이라는 리소스만 식별하고 회원 리소스를 URI에 매핑하면 된다.

API URI 재설계

1. 회원 목록 조회: /members
2. 회원 조회: /members/{id}
3. 회원 등록: /members
4. 회원 수정: /members/{id}
5. 회원 삭제: /members/{id}

 

원래 강의에서는 회원 등록에서 /members/{id} 로 표기가 되어있는데 필자는 /members 로 했다. 실제로도 이렇게 설계하기 때문이다. id는 등록에 필요없기 때문이다.

 

우리는 설계할 때 URI Resource만 식별해놓으면 HTTP Method인 GET, POST, PUT, DELETE가 조회, 등록, 수정, 삭제 역할을 수행할 수 있을 것이다. 여기서 URI Resource는 members이다. 참고로 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사용을 권장한다. 따라서 우리는 member가 아닌 members로 정의한다.

 

HTTP Method의 종류

- GET: 리소스를 조회한다.

- POST: 요청 데이터를 담아서 처리한다.

- PUT: 리소스를 대체한다. 해당 리소스가 없으면 생성한다.

- PATCH: 리소스를 부분 변경한다.

- DELETE: 리소스 삭제

- HEAD: GET과 동일하지만 메세지 부분을 제외하고 상태 줄과 헤더만 반환한다.

- OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)를 설명한다. 주로 CORS에서 사용한다.

- TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다.

 

HTTP Method - GET, POST

GET

 

GET은 리소스를 조회할 때 사용하는 메서드이다. 서버에 전달하고 싶은 데이터는 Query Parameter(String)을 통해서 전달한다. Query Parameter는 예를 들어 특정 회원을 조회한다고 하면 회원 고유값을 전달하는 것이다. Body를 전달할 수는 있지만 실무에서는 GET 메서드에서 Body를 사용하지 않는다고 한다.

 

POST

 

클라이언트에서 Body를 통해 서버로 요청해서 서버가 데이터를 처리하는 모든 기능을 수행한다. 주로 전달된 데이터로 신규 리소스를 등록하거나 변경된 프로세스를 바꿀 때 많이 사용하는 메서드이다. 필자는 지금까지 무언가를 생성할 때만 POST를 사용하자는 그런 고집이 있었는데 그렇지 않고 결국 마땅하게 적용할 메서드가 없으면 POST를 사용해도 될 것 같다는 생각이 들었다.

 

HTTP Method - PUT, PATCH, DELETE

PUT

PUT 메서드는 리소스가 있으면 대체하고 없으면 생성한다. POST와 다른 점은 클라이언트가 구체적인 리소스의 전체 위치를 알고 URI를 지정해서 서버에 전달한다는 점이다.

 

[리소스가 있을 경우]

 

클라이언트에서 /members/100 으로 리소스를 지정해서 데이터를 서버에게 보내게 되면 클라이언트가 보내준 리소스로 대체해버린다.

 

[리소스가 없는 경우]

 

클라이언트에서 /members/100 으로 리소스를 지정해서 데이터를 서버에게 보내게 되면 서버에 해당 리소스가 없어서 신규 리소스로 생성이 된다.

 

참고로 클라이언트가 /members/100 데이터에 username이 없고, age로 지정해서 보내게 되면 서버에서는 age를 업데이트 하는데 username이 날아가버린다. 기존 리소스를 새로운 리소스로 완전히 대체하기 때문에 리소스를 수정하기 어렵다.

 

PATCH

 

리소스를 부분 변경하는 것이다. age만 넣어서 보내게 되면 서버에서는 username은 그대로, age만 변경하게 되는 것이다.

 

DELETE

 

리소스를 삭제할 때 사용한다.

 

HTTP 메서드 속성

 

 

안전 (Safe Methods)

GET은 단순히 조회만 하기 때문에 안전하다. 다수 호출해도 데이터에 변경이 일어나지 않기 때문에 안전하다. 하지만 POST, PUT, PATCH, DELETE는 안전하지 않다.

 

만약 계속해서 호출하고 로그가 쌓여서 장애가 발생하는 상황이 발생한다고 해도 관심없다. 안전은 해당 리소스만 고려하기 때문에 그런 부분까지 고려하지 않는다.

멱등 (Idempotent Methods)

멱등이라는 것은 리소스에 대해 동일한 메서드를 여러번 호출하더라도 결과는 동일하다는 것이다. GET, PUT, DELETE, PATCH는 멱등하다. 하지만 POST는 멱등하지 않다.

 

- GET: 한 번 조회하든 100번 조회하던 같은 결과가 조회된다.

- PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다. 예를 들어, 똑같은 파일을 동일하게 업로드를 한다고 하면 결과가 다를까? 그렇지 않다.

- DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.

- POST: 멱등하지 않다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있기 때문이다.

 

멱등을 활용할 수 있는 사례가 있다. 바로 자동 복구 메커니즘이다. 클라이언트가 자동 DELETE를 호출했는데 서버에서 잘 되고 있는지 안 되고 있는지 응답이 없다. 클라이언트가 다시 자동 DELETE를 재시도 해도 멱등한다.

사용자 1 : GET ➡️ username: A, age: 20
사용자 2 : PUT ➡️ username: A, age: 30
사용자 3 : GET ➡️ username: A, age: 30

 

그리고 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지 고려하지 않는다. 똑같은 클라이언트가 동일한 요청을 했을 때만 멱등이 성립된다. 다시 말해, 동시성 문제까지 고려하지 않는다는 것이다.

 

캐시 가능 (Cacheable Methods)

웹 브라우저에 용량이 큰 이미지를 한번 요청하게 되면 그 다음에 똑같이 용량이 큰 이미지를 요청할 필요가 없다. 똑같은 이미지를 서버에서 다운로드 받게 되면 시간이 오래 걸리게 된다. 그래서 로컬PC에 웹 브라우저 저장을 하고 있을 때 캐시라고 한다.

 

보통 키로 만들어 놓는 것이기 때문에 GET, HEAD, PUT, PATCH가 모두 캐시 가능하지만 키로 구현하는 것이 어려운 PUT, PATCH를 빼고 주로 GET, HEAD를 주로 캐싱에 사용한다.

---

참고자료

 

- https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

- https://ebang.tistory.com/85

[인프런 김영한 강의 정리 - 인터넷과 http- ] - 4. HTTP METHOD