들어가며
- 이전 포스트에서 리소스를 잘 식별할 수 있는 URI 설계와 그렇게 설계함으로서 나올 수 있는 문제점들, 그리고 그러한 문제점을 해결하기 위해 HTTP 메서드를 가져온 것을 보았다.
- 이번 포스트에서는 HTTP 메서드들을 알아보고 각 메서드들의 특징과 사용 시점에 대해 논의한다.
HTTP 메서드
- HTTP 메서드는 리소스에 적용하는 어떠한 "행위"를 나타낼 수 있다.
- HTTP 메서드는 가장 대표적으로는 GET, POST, PUT, PATCH, DELETE로 나누어지며 부가적으로 몇 개의 메서드가 더 존재한다.
GET
- GET 메서드는 리소스를 조회하기 위해 사용하는 HTTP 메서드이다.
- 서버에 전달하고 싶은 데이터는 query(query parameter, query string)를 통해서 전달하며 메시지 바디를 사용하지 않고 URL에 쿼리가 적혀있는 특징이 있다.
- 그렇다고 메시지 바디를 사용하지 못하는가 라고 묻는다면 그렇지는 않다. 다만 GET메서드 방식에서 메시지 바디를 사용하는 방식을 잘 지원하는 곳이 없어서 권장하진 않는다.(Not Recommend)
POST
- POST는 요청한 데이터를 처리하기 위해 사용하는 HTTP 메서드이다.
- 서버에 전달하고 싶은 데이터는 메시지 바디를 이용하여 서버로 전달하며 GET 방식처럼 URL에 쿼리 스트링을 넣는 방식을 사용하지 않는다.
- 서버는 해당 데이터를 처리한다.
- 이는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능들을 수행한다.
- 일반적으로는 전달된 데이터를 통해 신규 리소스를 등록 또는 어떠한 프로세스 처리에 사용된다.
- 저 처리하다의 범위가 조금 애매한데 사실 POST요청이 올 시 요청 데이터를 어떻게 처리해야 한다는 스탠다드한 표준이 없으며 리소스의 특성마다 따로 정해야한다.
- 즉 요청 데이터를 처리하는 것의 구현 방식에 따라 추후에 나오는 PUT, DELETE 등의 동작도 POST로 수행할 수도 있다는 것이다.
PUT
- PUT 메서드는 어떠한 리소스를 대체시키기 위해 사용하는 HTTP 메서드이다.
- 만약 지정한 리소스가 존재한다면 PUT을 통해 서버로 보낸 데이터로 대체한다.
- 이때 대체한다는 것은 기존의 데이터를 제거하고 PUT 요청으로 보낸 데이터로 아예 바꿔치기한다는 것이다.
- 이는 만약 서버에 /members/100 번의 데이터가 다음과 같다고 가정하자.
{
"name":"kim",
"age":50
}
- 이때 만약 PUT을 통해 "age":20으로만 PUT 데이터가 들어온다면 요청이 수행되고 난 후의 /members/100 데이터는 다음과 같게 변한다.
{
"age":50
}
- 따라서 PUT을 통해 리소스를 수정할 경우, 주의 깊게 수정해야 한다.
- 만약 지정한 리소스가 존재하지 않는다면 새로 생성한다.
- PUT 메서드의 동작은 리소스의 생성으로만 범위를 축소시켜 생각해보면 POST와 크게 다른게 없는 것 같다.
- 하지만 매우 중요한 차이가 존재한다. 바로 클라이언트에서 리소스의 위치를 알고 있는지에 대한 것이다.
- POST의 URI를 보자. /members로만 되어있으며 리소스의 위치를 클라이언트는 모른다. 클라이언트는 POST 요청을 보낸 뒤에, 서버가 리소스를 생성하고 반환하는 생성된 리소스의 위치를 응답으로 받고 나서야 새로운 리소스의 위치를 알 수 있다.
- 하지만 PUT은 클라이언트가 리소스의 구체적 위치를 알고 있다. 위의 URI를 보면 members 중 100번 리소스에 요청에서 보낸 데이터를 생성하거나, 덮어씌우라는 HTTP 메시지이다.
PATCH
- PATCH는 리소스를 부분적으로 변경해야 할 때 사용하는 HTTP 메서드이다.
- 해당 요청이 들어올 경우에 서버는 /members/100에 리소스가 존재하는지 확인하고, "age" 필드가 존재하는지 확인한 다음 요청에서 들어온 값으로 수정을 수행한다.
DELETE
- DELETE는 지정된 위치의 리소스를 삭제하는 것을 요청하는데 사용되는 HTTP 메서드이다.
HTTP 메서드의 속성
- HTTP 메서드는 다음과 같은 속성들을 가진다.
- 안전(Safe)이란 몇 번을 호출해도, 해당 메서드가 리소스를 변경하지 않는 성질을 말한다.
- 예를 들어 GET의 경우 몇 번을 호출해도 리소스를 조회할 뿐이지 변경시키지 않는다. 따라서 GET 메서드는 안전한 특성을 가진다.
- 예를 들어 POST의 경우, 리소스의 생성 또는 처리를 통해 리소스를 변경할 가능성이 있다. 따라서 POST는 안전하지 않다.
- 멱등성(Idempotent)이란 한 번 호출하던 몇 번을 호출하던 그 결과가 동일한 성질을 말한다.
- 예를 들어 GET의 경우 한 번 조회하든, 100번 조회하든 그 결과는 동일하다. 따라서 GET 메서드는 멱등성을 가진다.
- PUT의 경우에도 자신이 보낸 데이터로 리소스가 "대체" 되므로 동일한 요청을 여러번 해도 리소스가 대체되었다는것 자체는 동일하다. 따라서 PUT 메서드는 멱등성을 가진다고 할 수 있다.
- POST의 경우 여러 번 호출하면 동일한 프로세스가 중복해서 발생할 수 있다. 즉 동일한 결과가 나오지 않을 수 있다. 따라서 POST 메서드는 멱등성을 가진다고 할 수 없다.
- 캐시가능(Cacheable)
- 캐시가능성은 응답 결과로 받은 리소스를 캐시해서 사용해도 되는가를 말한다.
- 스펙상으로 GET, POST, HEAD, PATCH는 캐시가능한 것으로 나오나 실무에서는 GET, HEAD 정도만 캐시가능성을 활용하여 캐시로 사용한다.
- 이는 POST, PATCH의 경우 본문 내용까지 캐시 키로 사용해야 하는데 이러한 요구사항에 맞추어 구현하는것이 쉽지 않기 때문이다.