HTTP 메서드

안녕하세요! 이번 포스팅에서는 인프런에서 김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 학습하고 정리의 목적으로 포스팅합니다. 이번 포스팅에서 다뤄볼 주제는 HTTP 메서드인 GET, POST, PUT, PATCH, DELETE와 올바른 설계란 무엇인가에 대해 설명합니다.

API URI 설계

먼저, 요구사항과 API를 CRUD에 초점을 맞춰 작성해보겠습니다.

 

요구사항	API
회원 1명 조회	/read-member-by-id
회원 다수 조회	/read-member-all
회원 등록	/create-member
회원 수정	/update-member
회원 삭제	/delete-member

 

지금 처럼 API를 작성하는 것은 올바른 설계가 아닙니다. URI는 리소스를 식별하는게 가장 중요합니다. 저의 요구사항에서 리소스에 해당하는 부분은 바로 회원입니다. 회원을 어떻게하는지는 관심이 아닙니다. 그럼 한번 수정해보겠습니다.

 

요구사항	API
회원 1명 조회	/members
회원 다수 조회	/members/{id}
회원 등록	/members
회원 수정	/members/{id}
회원 삭제	/members/{id}

 

보다 좀 더 읽히기 쉬워졌습니다.

나만그래요?

하지만 단순히 설계한 API를 가지고는 뭘하는지 알 수 없습니다. 리소스를 우리가 먼저 분리했다면 그 다음은 행위를 분리해야합니다. 이 행위를 메서드라고 합니다. 이제 이 요구사항에서 살펴봤던 행위들을 바탕으로 HTTP 메서드에 대해 알아보겠습니다.

 

HTTP 메서드

1. GET

리소스를 조회하는데 주로 사용하며, 서버에 전달하고 싶은 데이터는 URI의 쿼리(쿼리 파라미터, 쿼리스트링)에 담아 전달합니다. 서버는 해당 메서드와 쿼리를 바탕으로 동작을 수행합니다.

메시지 바디를 사용해서 전달할 수 있습니다. 하지만 서버에서 지원하지 않는 경우도 있기 때문에 가급적 권장하지 않는 방식입니다.

GET /search?q=beomseok&lang=ko

2. POST

저는 포스트에 대해 단순히 등록! 이라고만 알았는데, 좀 더 넓은 의미로 요청 데이터를 처리 한다라는 의미입니다.

메시지 바디를 통해 데이터가 들어오며, 데이터를 처리하는 모든 기능들을 수행합니다.

POST가 좀 아리까리 하지만 정리를 해보자면

• 새 리소스 생성(등록)
• 요청 데이터 처리, 프로세스의 상태가 변경이 되는 경우
• 다른 종류의 메서드로 처리하기 애매한 경우

이 경우에 주로 POST를 사용하시면 됩니다.

POST /member

Content-Type : application/json

{

​    "email" : "kobeomseok@email.com",

​    "password" : "1234"

}

3. PUT

이 강의를 듣기 전에 저는 PUT의 의미가 그냥 단순히 수정한다의 의미로 알고 있었습니다. 하지만 PUT의 의미는 리소스의 대체의 의미를 가집니다. 이 대체라는 말은 리소스가 있을 경우는 대체, 없을 경우는 생성의 의미입니다.

단순히 리소스가 없을 경우는 생성이 되지만, 리소스가 존재하는 경우 자칫 잘못하면 데이터가 덮어질 수 있기 때문에 주의해야합니다. 그렇다면 리소스가 존재하지 않을 경우에는 리소스가 생성되는데, 앞에서 설명드린 POST와는 무슨 차이가 있을까요?

클라이언트가 리소스를 아냐 모르냐의 차이입니다. POST는 클라이언트 입장에서 리소스의 위치를 모릅니다. 왜냐하면 서버가 리소스를 만들어주거나 프로세스를 처리하기 때문이죠. 하지만 PUT의 경우에 클라이언트가 PUT으로 요청할 경우, 데이터가 있을때는 요청 데이터로 덮어버립니다. 이 얘기는 클라이언트가 리소스 정보를 안다는 의미이기 때문에, 서버에서는 리소스 식별자를 보고 덮어쓸지, 새로 생성할지 판단하면 됩니다.

우선 10번 멤버가 존재하지 않다고 가정하고 PUT으로 생성해보겠습니다.

PUT /members/10

Content-Type : application/json

{
​    "email" : "kobeomseok@email.com",

​    "password" : "1234"
}

10번 멤버가 생성되었고, 제가 이전에 이해했던 수정의 의미로 PUT 요청을 해보겠습니다.

PUT /members/10

Content-Type : application/json

{
    "email" : "koko@email.com",
}

이렇게 될 경우 PUT은 덮어쓰기의 의미이기 때문에 기존에 갖고 있던 password는 사라지게 됩니다. 꼭 주의합시다.

4. PATCH

PATCH가 방금 앞에서 말했던 리소스 부분 변경의 의미입니다. PUT의 예제를 한번 더 사용해보겠습니다. 10번 멤버가 email, password 라는 정보를 갖고 있다고 가정해보겠습니다.

PATCH /members/10

Content-Type : application/json

{
    "email" : "koko@email.com",
}

이 경우, 10번 멤버의 password 속성은 그대로 유지되고, email만 요청한 값 대로 변경됩니다.

5. DELETE

간단합니다. 리소스를 제거하는 역할입니다.

DELETE /members/10

10번 멤버가 삭제되는 예시입니다.

HTTP 메서드 속성

설명 드리기에 앞서 해당 HTTP 메서드의 호출에 대한 특징입니다. 외부 요인들은 고려하지 않습니다.

1. 안전

GET 메서드는 호출해도 리소스를 변경하지 않기 때문에 안전합니다. 하지만 POST, PUT, PATCH, DELETE는 리소스를 변경하기 때문에 안전하지 못합니다.

2. 멱등성

멱등성의 뜻은 해당 기능을 몇번이나 수행해도 결과가 항상 똑같다는 뜻입니다. GET, PUT, DELETE는 멱등합니다. GET의 경우는 조회이기 때문에, PUT은 리소스를 덮어버리거나 생성하기 때문에 같은 메서드를 호출할 경우 결과는 항상 똑같습니다. DELETE는 해당 리소스를 삭제하는 메서드이기에, 호출을 여러번 해도 삭제되는 결과는 동일합니다.

하지만 POST와 PATCH는 멱등성을 보장하지 않습니다. POST를 먼저 예를 들어 보면, "사람 이름으로만 회원가입을 한다"라는 요구사항이 있을 경우 이름은 겹칠 수 있기 때문에 서버에서 이름이 중복되어도 회원가입을 할 수 있다는 경우로 가정해보겠습니다.

"고범석" 이라는 이름을 다섯번 회원가입을 POST로 요청할 경우 고범석 회원을 식별하는 식별자가 항상 늘어납니다. 즉, 응답이 호출할 때 마다 달라질 경우가 생기기 때문에 멱등성을 보장하지 않습니다.

PATCH의 경우, 예를 들어 PATCH를 이용해 회원의 나이를 더하는 요구사항이 있다고 가정해봅시다. 요청 바디(json)에서 "operation"이라는 key에 "add"라는 value가 있을 경우, 나이를 더하는 서버의 로직이 있다고 해봅시다.

"age" : 10, "operation" : "add"를 계속 요청할 경우, 기존 회원의 나이를 요청한 만큼 계속 10씩 더하고 응답해줄 것입니다. 그렇기 때문에 멱등성이 보장되지 않습니다. PATCH가 멱등하지 않다는게 저는 와닿지 않았는데, 강의에서 다른 분의 질문을 통해 알게 되었습니다.

3. 캐시가능

GET, POST, PATCH는 캐시가 가능합니다. 하지만 POST, PATCH의 경우 구현이 복잡하기에 주로 GET을 캐시로 사용하며 이 부분은 좀 더 공부가 필요할 것 같아서 여기까지만 작성하겠습니다. 추후에 캐시에 대해 포스팅 해보도록 할게요.

포스팅은 여기서 마무리하겠습니다. 혹시나 틀린 정보를 작성했을 경우 꼭 지적 부탁드립니다!