[HTTP] HTTP 메서드와 활용

 

 

 

웹에서 HTTP를 통해 통신하는 경우를 생각해보자.

클라이언트는 주소 창에 URI를 입력해 서버에게 요청한다.

 

이 때 API URI는 어떻게 설계됐을까?

 

(https://aws.amazon.com/ko/what-is/api/ API에 대한 설명은 이쪽을 참고하자.)

 

 

URI는 리소스 식별에 집중해야 한다.

 

여기서 리소스는 웹 사이트의 회원이 있다면 그 회원 자체를 의미한다.

 

회원을 등록하는 작업이 있다면 회원 / 등록 으로 구분해서 생각해야 한다.

 

 

 

 

 

즉, 왼쪽 예시보다 오른쪽 예시가 더 괜찮게 설계됐다고 할 수 있다.

 

이렇게 되면 URI가 중복될 수 있는데, 이럴 때 HTTP 메서드를 사용한다.

 

 

 

---

 

 

 

GET

 

 

리소스를 조회할 때 주로 사용한다.

서버에 전달하는 데이터는 쿼리를 통해 전달한다.

 

 

 

 

GET 메서드를 통해 통신하는 과정을 살펴보자.

 

 

 

 

 

 

HTTP 요청 메세지를 생성하고 보낸다.

서버는 100번 회원을 데이터베이스에서 찾은 후 특정 데이터 타입으로 만든다.

 

 

 

 

 

그 후 서버가 만든 HTTP 응답 메세지를 클라이언트가 받는다.

 

 

 

POST

 

 

 

GET 메서드가 리소스를 조회할 때 사용했다면, POST 메서드는 주로 서버에게 요청 데이터의 처리를 부탁할 때 사용된다.

 

요청 데이터는 메세지 바디를 사용해 전달한다.

 

 

 

 

POST 메서드를 통해 통신하는 과정을 살펴보자.

 

 

 

 

 

 

일단 POST 메서드로 요청 메세지를 보낸다.

 

이 때 서버와 클라이언트 사이에는 클라이언트가  /members + POST 메서드로 데이터를 보내면 서버는 어떤 식으로 데이터를 조작할 지 약속이 돼 있다. 여기서는 등록하는 작업을 수행한다고 하자.

 

 

 

 

서버는 받은 데이터를 열어서 데이터베이스에 저장한다.

 

 

 

 

성공적으로 등록됐을 시 위와 같이 HTTP 응답 메세지를 보낸다.

 

 

POST는 다양한 작업을 처리할 때 사용된다.

 

작업이 하나로 정해지지 않았고, 리소스 URI에 POST 메서드로 요청이 오면 요청 데이터를 어떻게 처리할 지 리소스마다 따로 정해야 한다.

 

주로 새 리소스를 생성하고 등록할 때 사용되고, 요청 데이터를 처리할 때도 사용된다.

 

사실 어떤 작업을 해라! 라고 정해진 바가 없는 메서드라서.. 딱 잡아서 말하기는 애매하다.

 

POST는 모든 작업을 수행할 수 있지만, 데이터를 조회할 때는 GET메서드를 사용하는 편이 캐싱 작업 등 여러 부분에 있어 유리하므로 GET을 사용하기 힘든 경우 POST를 사용한다고 생각하자.

 

 

 

PUT

 

 

리소스를 대체할 때 사용한다. (덮어쓰기)

리소스가 있으면 내용에 상관없이 대체, 리소스가 없으면 생성한다.

 

POST와는 다르게 클라이언트가 리소스의 위치를 알고 URI를 지정한다. (members/100)

 

 

 

 

PATCH

 

리소스의 부분을 변경할 때 사용된다.

PUT은 기존 리소스를 새로운 리소스로 통으로 갈아치웠다면 PATCH는 리소스의 부분만 변경한다.

 

 

DELETE

 

 

직관적이다. 리소스를 지울 때 사용한다.

 

 

 

---

 

 

 

선 정리

 

 

 

그런데.. POST로 모든 작업을 수행할 수 있으면 POST로 통일해서 작업하면 되지 않을까? 라고 생각할 수 있다.

 

각각의 HTTP 메서드들에는 특성이 있고, 특성을 잘 활용해 메서드를 사용해야한다.

즉, 특정 작업을 수행할 때는 POST보다 다른 메서드를 사용하는게 합리적인 경우가 있다.

 

 

Safe

 

 

호출해도 리소스를 변경하지 않음을 의미한다.

표를 통해 어떤 메서드가 안전한지 확인하자.

 

 

 

Idempotent

 

 

몇 번 호출하든 결과가 동일함을 의미한다.

 

GET : 몇 번 조회하든 결과가 같다. (재요청 중 리소스가 변경됨은 고려하지 않는다.)

PUT : 같은 요청을 몇 번 하든 최종 결과는 같다.

DELETE : 두 번 삭제한다고 해도 최종적으로 삭제된 상태다.

POST : 멱등이 아니다.

 

자동 복구 매커니즘에 사용된다.

 

 

 

Cacheable

 

 

응답 결과 리소스를 캐시해서 사용할 수 있음을 의미한다.

 

GET HEAD 정도.

 

 

 

 

---

 

 

 

 

클라이언트에서 서버로 데이터를 전송할 때는 쿼리 파라미터를 사용하거나 메세지 바디를 사용한다.

 

몇 가지 예시 상황을 살펴보자.

 

 

정적 데이터 조회

 

 

 

 

웹사이트에서 GET 메서드로 특정 이미지를 요청하면 서버는 데이터베이스에서 해당 이미지를 찾고 응답한다.

 

이미지나 정젝 텍스트 문서를 조회할 때 사용되고, 쿼리 파라미터 없이 GET 메서드만을 사용해 조회할 수 있다.

 

 

 

동적 데이터 조회 

 

 

 

 

클라이언트가 쿼리 파라미터를 GET 메서드를 통해 서버에게 요청하고, 서버는 쿼리 파라미터를 기반으로 결과를 동적으로 생성해 반환한다.

 

검색, 정렬에서 주로 사용된다.

GET과 쿼리 파라미터를 사용해 조회한다.

 

 

 

 

HTML Form 사용

 

 

 

 

HTML의 태그 중 하나인 Form태그를 통해 데이터를 전송할 수 있다.

 

웹 브라우저에서 submit 버튼을 누르면 폼의 데이터를 읽어서 HTTP 요청 메세지를 생성한다.

 

이 때 GET 메서드와 POST 메서드 모두 사용할 수 있지만 리소스의 변경이 발생하는 경우는 POST를 사용해야 한다.

 

 

 

파일까지 함께 전송해야 할 때는 multipart/form-data를 사용한다.

 

HTTP 요청 메세지에서  XXX로 입력 부분을 잘라서 처리한다.

 

 

 

HTML Form은 GET과 POST방식만 지원한다.

 

 

 

HTTP API 데이터 전송

 

 

 

모바일 환경에서 서버로 바로 데이터를 전송해야 하거나 서버와 서버 간 통신에서 사용된다.

 

그냥 바로 HTTP 요청 메세지를 만들어서 사용한다.

 

Content-Type은 json을 주로 사용한다.

 

 

 

---

 

 

 

이제 HTTP URI API를 설계해보자.

 

 

 

 

수정 할 때는 PATCH PUT POST를 적절히 사용하되, 애매하면 POST를 사용하자.

 

 

POST 메서드로 신규 리소스를 등록할 때 클라이언트는 등록될 리소스의 URI를 모르지만, 서버가 새로 등록된 리소스의 URI를 생성해 응답 메세지에 넣어준다.

 

이런 형식을 컬렉션이라고 부른다. (/members가 컬렉션)

 

 

 

 

파일을 등록 할 때는 PUT을 사용해보자.

POST는 임의로 정할 수 있는데 여기서는 대량 등록으로 설정하자.

 

PUT 메서드를 사용할 때는 POST 메서드와 달리 클라이언트가 리소스의 URI를 알고 있다.

 

이런 형식을 스토어라고 부른다. (/files가 스토어)

 

 

등록은 대부분 POST 메서드를 사용한다.

 

 

 

 

 

HTML 폼을 사용하면 GET 과 POST 메서드만 사용할 수 있다.

 

이런 제약을 극복하기 위해 /new /edit /delete 와 같이 동사로 된 리소스 경로를 사용한다. (컨트롤 URI)

 

 

URI는 리소스 식별에 집중해서 설계돼야하지만, 리소스 식별에 작업 요소가 추가되는 경우가 있다.

이 경우 컨트롤 URI를 사용하자.