HTTP Method
주어진 리소스에 대한 행동을 나타내는 방식이다. 특정 메서드를 활용한 요청 결과값을 서버가 미리 만들어두고, 클라이언트가 요청할 때마다 메서드에 맞는 결과를 반환한다. 이는 클라이언트와 서버 간의 약속으로, 협의가 잘 되어 있다면 굳이 메서드를 구분할 필요가 없다. 하지만 메서드를 적확하게 사용하면 API가 명확해지고 이해와 사용이 쉬워지기 때문에 표준을 지키는 편이 좋다.
REST API
API 방식 중 가장 많이 언급되는 방식인 REST API는 HTTP Method를 아름답게 사용한 API이다. 자세한 내용은 [TIL 5] - [CS] REST/RESTful API 참고.
Method 종류
대표적인 HTTP Method로는 GET, POST, PUT, DELETE가 있고, 추가로 PATCH가 있다.
| Method | Description |
|---|---|
GET | 데이터를 가져온다 |
POST | 데이터를 등록한다 |
PUT | 데이터 전체를 바꾼다 |
PATCH | 데이터 일부분을 바꾼다 |
DELETE | 데이터를 삭제한다 |
이 외에 HEAD, OPTIONS, TRACE, CONNECT가 있는데, 뒤의 두 가지는 거의 사용하지는 않는다.
| Method | Description |
|---|---|
HEAD | GET과 비슷하나 응답 본문(body)가 없다. 라우터가 제대로 작동하는지 확인하는 데 사용할 수 있다. |
OPTIONS | 타 사이트로 요청을 보낼 때 사용한다. preflight와 연결된다 |
TRACE | 프록시 서버를 거쳐 최종 서버로 가는 도중 어떤 헤더가 변경되었는지 추적한다. 거의 쓰지 않는다. |
안전한 메서드와 멱등성 메서드
안전한 메서드는 아무리 요청을 보내도 서버에서 상태 변화를 일으키지 않는 메서드를 말한다. GET, HEAD, OPTIONS, TRACE 등이 있다. 예를 들어, GET 요청을 1만 번 보낸다한들 서버가 보내는 데이터의 상태는 늘 똑같다.
반면, POST의 경우, 자원을 추가하여 서버 변화를 일으키므로 안전한 메서드가 아니다.
멱등성 메서드는 같은 요청을 여러 번 보내도 서버에서는 한 번 바뀐 것과 다름 없음을 의미한다. 안전한 메서드(GET, HEAD, OPTIONS, TRACE)를 포함하여 PUT, DELETE가 있다.
put은 A를 B로 변환시키지만, 1만 번을 실행해도 B가 더는 변하지 않는다. DELETE 역시 1번 유저를 한 번 삭제하면 더는 다른 유저를 삭제하지 않는다. 때문에 이들은 멱등하다.
반면, POST는 1만 번 실행하면 새로운 자원이 1만 개 생성되므로 멱등하지 않고, 안전하지도 않다. PATCH는 사용 방식에 따라 다른데, 단순히 A.name를 gold에서 silver로 바꾼다면 멱등하겠지만, A.age를 계속 증가시키는 방식이라면 멱등하지 않다.
상태 코드
HTTP 요청 성공 여부를 알려주는 상태 코드는 5개의 그룹으로 나뉜다. 상태 코드는 브라우저가 다음에 해야 할 일을 추측할 수 있게 하므로, 최대한 지키는 편이 좋다. 중간중간 비어있는 코드 번호는 개발자가 임의로 지정해 재량으로 사용할 수 있다.
자주 사용하는 상태 코드 위주로 나열한다.
1xx - 정보
100: 계속하라는 응답이며, 주로 스트리밍 같은 서비스에서 사용한다.101: 프로토콜을 바꿀 때 사용한다. HTTP에서 WS으로 변경하는 등.
2xx - 성공
200: 데이터 요청이 성공했을 때 사용한다.201: 자원이 새로 생성되었을 때 사용한다.204: 요청이 성공했지만, 응답할 콘텐트가 없을 때 사용한다.206: 콘텐트의 일부분만 받았을 때 사용한다.
3xx - 리다이렉트
300: 애매한 요청에 대한 응답이다.A와B중 어느쪽을 응답해야 할지 애매할 때 하나를 확실히 정하게끔 응답할 때 사용한다.301: 자원의 영구 이동을 의미한다. 도메인 변경 등에 사용한다.302: 자원의 임시적인 이동을 의미한다.304: 캐시를 목적으로 사용한다.307: 임시 이동을 의미하나,302와 다르게HTTP Method가 변경되어서는 안 된다. 즉,a.com에서POST를 사용하여b.com으로 리다이렉트했다면b.com에서도POST를 사용해야 한다.
4xx - 클라이언트 에러
400: 요청이 잘못되었다.401: 로그인해야 만 볼 수 있다.403: 로그인해도 자격이 없으면 볼 수 없다.404: 해당 주소가 없다. 간혹 해커의 승부욕 자극을 회피할 목적으로403대용으로 사용하기도 한다.405: 요청한 메서드 금지를 의미한다.406: 컨텐트 협상 실패를 의미한다.Accept에 해당하는 것이 없는 경우 사용한다.408: 요청 시간이 너무 오래 걸려 연결을 끊었다.413: 요청한 데이터가 너무 크다.414: 주소가 너무 길다.418: 찻주전자가 아니라는 개발자 유머(특: 웃기지 않음)426: 프로토콜 업데이트가 필요하다.429: 요청이 너무 많다.431: 헤더가 너무 크다.451: 법적인 이유가 담겨 있다.
5xx - 서버 에러
500: 서버에서 알 수 없는 에러가 발생했다.501: 아직 요청을 지원할 API를 안 만들었다.502: 서버 앞 중간 매체(프록시, 게이트웨이 등)에서 에러가 발생했다.503: 서비스가 불가능하다.504: 중간 매체에서 시간 초과에 걸렸다.505: 그 HTTP 버전은 사용하지 말아라.
상태 코드는 약속일 뿐, 의무는 아니기에 꼭 따라야 하는 것은 아니지만, 몇몇 상태 코드는 반드시 따라야 하는 경우가 있다. 예를 들면, 301 코드는 브라우저에게 영구적으로 리다이렉션해야 함을 의미하여 강제 동작시키기 때문이다. 이는 SEO에 영향을 준다.
임의로 코드를 사용하고 싶다면 비어 있는 번호를 사용하고, 어떤 코드를 사용할지 애매하면 대표 코드를 사용한다.
참고
Inflearn ZeroCho - 비전공자의 전공자 따라잡기 - 네트워크, HTTP
MDN docs - HTTP 요청 메서드
MDN docs - HTTP 상태 코드
오엔 - [ RESTful API] PUT과 PATCH의 차이 - 멱동성을 보장하는 PUT, 멱등성을 보장하지 않는 PATCH
NakedStrength - [HTTP] 301과 302 Redirect의 차이
