[HTTP 웹 기본 지식] HTTP 메서드 - 메서드 종류 (GET, POST, PUT, PATCH, DELETE)

🌱 HTTP Method - 메서드 종류

HTTP  주요 메서드 종류

• GET : 리소스를 조회
• POST : 요청 데이터를 담아서 처리
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

HTTP  기타 메서드 종류

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

 

 

1. GET: 리소스 조회

• 특정한 리소스를 가져오도록 요청한다.
• GET 요청은 데이터를 가져올 때만 사용해야 한다.
• 서버에 전달하고 싶은 데이터는 query string을 통해 전달
• GET 요청에 메시지 바디에 데이터를 담을 수도 있지만 이는 권장하지 않으므로 사용하지 말자.
• 캐시가 가능하다.
• 멱등하다.

 

2. POST: 요청 데이터 처리, 주로 등록에 사용

• 요청 데이터 처리를 담당한다.
• 메시지 바디를 통해 서버로 데이터 전달한다.
• 서버는 넘어온 데이터를 처리한다.(바디를 통해 들어온 데이터를 처리하는 모든 기능 수행)
  • 메시지 바디 타입(html, json..)은 Content-Type에 나타낸다.
• 멱등 아니다.
  • 결제를 생각해보면 한번 호출하고 두번 호출하는 것은 다르다.
• 주로 전달된 데이터로 신규 리소스 등록하거나 변경된 프로세스를 바꿀 때 많이 이용한다.

 

POST 기능

1. 새 리소스 생성(등록)
   • POST는 리소스의 URI를 모르지만 서버가 새로 등록된 리소스 URI를 생성해준다.
   • 이렇게 서버가 리소스 URI를 생성하고 관리하는 것을 컬렉션(Collection)이라고 하며, 컬레션은 /members를 말한다.
2. 요청 데이터 처리✨
   • 프로세스의 상태 변경해야 하는 경우 -> 예) 결제완료 -> 배달시작 -> 배달완료
   • 기본적으로 리소스만 가지고 URI를 설계하는 것이 이성적이지만, 어쩔 수 없는 경우 컨트롤 URI로 설계 (어쩔 수 없이 동사가 들어갈 수도 있음)
     
   • 예) POST/orders/{orderId}/start-delivery (컨트롤 URI)
3. 다른 메서드로 처리하기 애매한 경우
   • ajax를 통해 데이터를 조회할 때 메시지 바디에 담고 싶어서 POST를 사용할 수도 있다.
   • 하지만 조회할 때는 왠만하면 GET을 사용하자.
     • 그 이유는 캐싱!

 

3. PUT: 리소스 대체, 해당 리소스가 없으면 생성

1. 리소스가 있을 경우 -> 덮어씀

 

2. 리소스가 없을 경우 -> 생성

 

• 리소스가 없으면 새로운 리소스를 생성하고, 리소스가 있으면 리소스를 완전히 대체한다. (덮어버린다.)
• POST와의 유일한 차이점은 PUT은 클라이언트가 리소스의 위치를 알고 URI를 딱 지정한다. ex) /members/100
  • 이처럼 클라이언트가 리소스 URI를 알고 관리하는 것을 스토어(Store)라고 하며, 스토어는 /members가 된다.
• 하지만 POST는 클라이언트가 리소스의 위치를 알지 못하고 자동으로 만들어준다. ex) /members
• 멱등하다.

PUT /members/100 HTTP/1.1
Host: example.com
Content-type: application/json

{
      "name": "minsu",
      "age": 20
}

 

❗ 잠깐 !

리소스를 완전히 대체한다는게 무슨 말일까?

만약 기존 데이터가 아래와 같다고 가정해보자.

{
      "name": "minsu",
      "age": 20
}

여기서 PUT 메서드를 사용해서 age만 30으로 변경한다면 어떤 일이 벌어질까?

PUT /members/100 HTTP/1.1
Host: example.com
Content-type: application/json

{
      "age": 30
}

→ age만 수정하면 되기 때문에 json 데이터는 age만 넘겨서 30으로 변경했다.

그러면 PUT의 완전히 대체된다는 특징 때문에 name이라는 필드는 없어지고 age만 남게된다.

 

만약 내가 회원가입을 하고 회원수정을 나이만 수정하고 싶은데 PUT 메서드를 사용하게 되면 나의 아이디, 비밀번호, 이메일... 이러한 중요한 정보들을 모두 잃을 수 있다. 😨

 

4. PATCH: 리소스 부분 변경

내가 의도한대로 리소스의 부분만 수정되게 하려면 바로 PATCH를 사용하면 된다.

PATCH /members/100 HTTP/1.1
Host: example.com
Content-type: application/json
{
      "age": 30
}

그러면 위와 같이 age만 30으로 변경해도 데이터는 name과 age 모두 그대로 남게된다.

• PATCH는 멱등이 되도록 할 수 있고, 멱등이 안되게 할 수도 있다.
• 예를 들어보자.
• 참고: https://www.inflearn.com/questions/110644

{
      "age": 22
}

이것은 멱등이다.

하지만 아래는 멱등이 아니다.

{
      "age": 22,
      "calc": add,
      "plusNumber": 1
}

이것은 계속 메서드를 수행할 때마다 +1 더하는 수행을 한다고 했을 때 age의 값이 변한다.

 

5. DELETE: 리소스 삭제

• 지정한 리소스를 삭제
• 멱등하다.

DELETE /members/100 HTTP/1.1
Host: example.com

 

정리 (POST, PUT, PATCH)

• POST는 리소스의 위치를 알지 못해도 자동으로 생성해준다.
• PUT은 리소스의 위치를 알고 있고, 기존 리소스를 삭제하고 완전히 대체하기 때문에 중요한 데이터는 PUT을 사용하면 안된다.
• 중요한 데이터를 부분 수정하려면 PATCH를 사용한다.

 

---

❓ Question

1. 배달 상태를 변경할 때 PATCH를 사용해야 하는 것이 아닌가?

https://www.inflearn.com/questions/110170/post-orders-orderid-start-delivery-%EC%A7%88%EB%AC%B8%EC%9E%88%EC%8A%B5%EB%8B%88%EB%8B%A4

배달의 상태를 변경하다는 것은 단순히 해당 리소스의 값을 변경하는 정도로 끝나는게, 아니라 내부에서 매우 큰 프로세스가 실행된다.

이렇게 해당 리소스만 변경하는게 아니라 내부 프로세스를 실행해야 할 때는 PATCH 보다는 POST를 사용하는 것이 좋다.

단순히 회원 정보를 변경하는 것처럼 특정 리소스의 데이터를 변경할 때 PATCH를 사용하는 것이 좋다.

 

추가로,

POST /orders/{orderId}/delivery/{배달 상태값} 같은 방식으로 설계하기가 좀 애매한 점이 실무에서는 배달 상태값을 단순히 바꾸는게 아니라 배달 상태에 따른 전달 데이터가 각각 다를 확율이 매우 높다.

예를 들어서 배달에서 전달하는 데이터와 취소에서 전달하는 데이터가 매우 다를 것이다.

따라서 다음과 같이 다르게 정의되는게 더 나은 설계일 수 있다.

 

POST /orders/{orderId}/delivery/배달

{데이터A, 데이터B, 데이터C}

POST /orders/{orderId}/delivery/취소

{데이터D,데이터E}

---

 

2. /{id}가 의미하는 것은?

https://www.inflearn.com/questions/517777/id-%EA%B0%80-%EB%AD%98%EA%B9%8C%EC%9A%94

 

path (/members/1)와 query (/members?name='david')는 리소스를 식별하기 위해 함께 쓰인다.

path는 주로 계층 구조로 된 정보를 포함하고, query는 주로 비계층 구조로 된 정보를 포함한다.

 

https://velog.io/@jcinsh/Query-string-path-variable

위의 사이트를 참고하여 올바른 URL 설계에 대해 알아보자.

---

 

3. 회원 정보를 수정할 때, PATCH를 사용하면 변경되는 필드가 무엇이냐에 따라 코드를 다 따로 작성해야하기 때문에 중복되는 코드가 많아진다. 그래서 PUT으로 전체를 덮어쓰게끔 했더니 하나의 정보만 변경해도 모든 데이터를 보내야하는 비효율성 문제가 발생하였다. 만약에 PATCH를 사용한다면, 어떤 식으로 구현해야 효율적인 코드를 짤 수 있을까?

https://www.inflearn.com/questions/117477/put-patch%EC%97%90-%EB%8C%80%ED%95%9C-%EC%A7%88%EB%AC%B8%EC%9E%85%EB%8B%88%EB%8B%A4

 

update 쿼리를 동적 쿼리가 되도록 구성하시면 된다.

예를 들어 클라이언트에서는 변경된 값만 서버에 넘기고, 서버에서는 필드에 값이 있는 경우에는 update set 조건으로 추가하고, 값이 null인 경우에는 update set 조건에서 제외하는 식으로 만들면 된다.

(동적 쿼리에 대해 공부해보자!!!)

---

 

4. POST, PUT 모두 리소스를 생성할 수 있는데 둘의 차이점은 무엇인가?

https://www.inflearn.com/questions/525579/post%EC%99%80-put

 

POST는 리소스의 생성을, PUT은 리소스의 대체(replace)를 의미한다.

 

가령, POST는 클라이언트가 서버에 요청을 보낼때마다 새로운 리소스를 생성하고 생성한 리소스의 아이디를 반환한다. 그래서 같은 요청을 반복하면 리소스 아이디가 새롭게 바뀝니다.

반면 PUT은 리소스의 대체이기에, 처음 리소스가 없다면 새로 생성한 리소스 아이디를 반환하고, 이후에 계속 같은 요청을 보내면 처음 생성했던 리소스의 아이디만 반환합니다.