[HTTP] HTTP Method

목차

• HTTP API를 만들어보기
• HTTP 메서드 - GET, POST
• HTTP 메서드 - PUT, PATCH, DELETE
• HTTP 메서드의 속성

 

---

 

 

HTTP API를 만들어보자

 

 

회원 목록 조회 - 회원 리스트를 확인할 수 있다.

회원 조회 - 회원 리스트에서 선택해서 상세화면으로 들어가면 회원을 조회할 수 있다.

회원 등록, 수정, 삭제가 필요하다.

 

 

---

 

 

 

 

회원을 조회하고 등록, 수정, 삭제하는 것이 리소스(자원)가 아니다.

미네랄을 캐는 행위가 리소스가 아니라, 미네랄 그 자체가 리소스이다.

회원이라는 것만 리소스로 식별하면 된다. 그것을 URI에 매핑하면 된다.

그래서 URI 는 다음과 같이 설계되어야 한다.

 

 

---

 

 

 

리소스에 집중해서 URL를 설계했는데, 조회 등록 수정 삭제는 어떻게 구분해야 하는거지?

답: HTTP Method

 

 

리소스와 행위를 분리해야 한다. (미네랄과 미네랄을 캐는 행위를 분리해야 한다.)

URI는 리소스를 판별하는 용도로 사용해야 하고, 리소스의 행위를 판별하는 것에 사용하면 안 된다.

행위는 HTTP Method를 통해 구분할 것이다. 그래서 우리는 URI에서 리소스만 식별하면 된다.

 

 

---

 

HTTP 메소드 - 클라이언트가 서버에 요청을 할 때, 기대하는 행동

 

 

GET: 리소스 조회 (데이터 주세요~)

POST: 요청 데이터 처리, 주로 등록에 사용 (데이터를 줄테니 등록을 하거나 처리를 해주세요~)

PUT: 리소스를 대체, 해당 리소스가 없으면 생성 (파일을 폴더에 넣는 것처럼 없으면 넣고 있으면 덮어쓰기)

PATCH: 리소스 부분 변경 (특정 필드를 수정할 때 사용)

DELETE: 리소스 삭제

 

 

 

---

 

 

HTTP method - GET

 

 

Get의 경우 리소스를 조회할 때 사용한다. URL에 있는 path에 해당하는 자원을 요청하는 것이다. 

예를 들어, 검색 엔진에 내가 원하는 검색어를 넘겨야 하는데 이것을 Query parameter를 통해 넘긴다.

HTTP에서 GET method를 사용할 때도 body를 사용할 수 있다. (최근 스팩에서는 허용이 된다.)

하지만, 지원하지 않는 서버들이 많아서 실무에서는 사용하지 않고 Query String, Query parameter를 통해 데이터를 서버로 전달하는 것이 관례이다.

 

 

 

 

---

 

HTTP method - POST

 

 

 

• /members 에 데이터를 줄 것이고, 등록 혹은 처리를 요청하는 것이다.
• 클라이언트가 /members 에 post를 보내면 그 데이터는 서버가 저장하거나, 내부 프로세스에 사용할 것을 약속 되어 있어야 한다.
• 이것이 등록이라고 가정하면, /members 밑에 신규 식별자를 생성하고 오른쪽 사진은 /members/100 에 생성 된 것을 확인할 수 있다.
• 그 후, 아래와 같이 응답한다.

• 신규 생성은 201 Created 로 보내지만 200으로 보내도 된다.
• 201로 보내면 Location을 추가해서 보내는데 Resource가 생성된 경로를 보내준다.

 

---

 

POST는 등록만 의미하는 것이 아니다. 진짜 의미를 살펴보자.

 

 

 

 

분명 URI는 리소스를 식별하는 것에만 사용해야 된다고 했지만, 어쩔 수 없이 리소스의 행위를 URI에 포함시키는 경우가 존재한다. 리소스 URI 형태로 구현해야 하지만, 어쩔 수 없는 경우 컨트롤 URI를 사용해서 리소소와 리소소의 행위를 URI에 포함시키는 작업이 필요하다.

더 나아가 JSON으로 GET을 보내려면 참 애매 해지는데, 애매하면 POST를 사용하면 된다.

 

사실 POST는 메세지를 담아서 보내는 모든 것을 할 수 있다.

하지만, 우리는 Packet이라는 개념을 배웠다.

 

서버끼리는 일종의 약속이 존재하고, GET으로 Request를 보내면 캐싱을 하게 된다. 

POST로 Request를 받으면 서버는 캐싱을 하기가 곤란하다.

그래서 조회할 때는 GET을 쓰는 것이 유리하다.

 

 

---

 

 

완전히 대채하는 것이 PUT이다. 즉, body에 데이터를 실어 PUT으로 보내면 그 리소스는 내가 보낸 데이터가 된다.

여기서 중요한 것은 요청 메세지를 살펴보면 request-target인 path를 정확히 알고 있다.

클라이언트가 리소스의 전체 위치를 알고 URI를 지정하는 것이다.

이것이 POST와 차이점 이다.

 

POST는 /members 에 요청을 하게되고 정확히 리소스가 어디에 생성되는지 알지 못한다.

하지만, PUT의 경우 정확히 내가 리소스를 넣을 공간을 지정해야 하는 것이다.

리소스의 위치를 정확히 알고 있는 것이다.

 

 

 

 

PUT은 기존 리소스를 완전히 삭제하고, 데이터가 추가된다.

그래서, PUT의 용도는 리소스를 수정하는 것이 아니라 갈아 치우는 용도이다.

수정할 때는 PATCH를 사용해야 한다.

 

 

---

 

 

리소스를 수정하고 싶을땐 PATCH를 사용해라

 

 

 

PATCH는 PUT의 수정 문제점을 보완하기 위해 뒤에 나온 메소드이다.

그래서 간혹 PATCH를 받지 못하는 서버가 존재하는데, 이때는 POST를 사용하면 된다.

POST는 전부 사용 가능하기 때문이다.

 

 

 

---

 

 

리소스를 제거할땐 DELETE를 사용해라

 

 

 

 

---

 

 

 

HTTP method의 속성

HTTP 메서드의 경우 각 특징이 존재한다. 이를 배워보자.

• 안전(Safe Methods)
• 멱등(Idempotent Methods)
• 캐시가능(Cacheable Methods)

 

GET의 경우 현재 Body에 데이터를 넣을 수 있지만, 지원하지 않는 서버가 존재해서 웬만하면 넣지 않는 것이 좋다.

 

 

---

 

호출했을때 변경이 이루어지지 않으면 안전하다

 

GET 또한 계속 요청을 하게 되면 한번 호출할때마다 Log가 쌓이게 되고 Log가 쌓여서 서버가 터질 수 있지 않을까?

안전은 해당 리소스가 변하는지 안변하는지만 생각하는 것이다. 너무 깊게 생각하지는 않는다.

 

 

---

 

 

 

 

멱등이 왜 중요할까?

한 번 호출 했을때 응답이 없으면 재요청의 가능하다는 의미이다.

두 번 호출해도 같은 결과가 나오기 때문이다.

그래서 자동 복구 메커니즘을 사용할 수 있다.

 

 

단, 같은 행위를 하는 것이지 외부 요인에 의해 데이터가 변경되면, 변경된 데이터를 갖고 오는 것이 당연하다. 이는 멱등과 관계 없는 상황이다.

 

 

---

 

 

Cache는 뒤에서 설명하겠다.

예를 들어, 웹 브라우저에서 대용량 이미지를 요청했다고 가정하자.

그러면, 다음 요청에서 같은 이미지를 받아 온다면, 인터넷 망을 통해 다시 다운로드 하게 된다.

이는 굉장히 불필요한 작업을 하는 것이기에 우리는 로컬 PC의 웹 브라우저에서 저장을 하고 있다.

이를 Cache라고 한다. 물론 중간 Cache 서버부터 다양한 메커니즘이 존재한다.

중요한 것은 불필요한 작업을 하지 않게 재요청에 대한 기억을 하고 있다는 것이다.

 

캐시를 하려면 똑같은 리소스에 대해 키가 맞아야 하는데 POST는 body 안에 데이터를 보내서 작업하기가 힘들다. 그래서 대부분 구현이 잘 되어 있지 않다. 그래서 실무에서는 주로 GET 만 사용한다.