Http Method와 status code

HTTP Method 종류

GET

GET은 데이터를 조회하기 위해 사용됩니다. 추가적으로 서버에 전달하고 싶은 데이터를 쿼리스트링을 통해서 전달할 수 있습니다. Body로도 전달할 수 있지만 지원하는 서버가 많이 없어 권장되지 않는다.

POST와 Get의 가장 큰 차이점은 *멱등성이다(idempotent).  

POST

POST 요청은 주로 데이터를 신규 리소스로 등록하거나, 프로세스의 처리에 사용한다. 예시로는 주문 전송을 생각하면 될 것이다.

PUT과 POST의 가장 큰 차이점은 PUT은 Client가 자원의 디렉터리를 지정할 수 있을 때 사용하고, Post는 Client가 자원의 디렉터리를 저장할 수 없을 때 사용된다. 

 

form을 통해서 보내면 쿼리 파람 형식으로 서버에게 전송됨 대신 바디에 들어감 

content-type이 필수로 들어가게 된다.

 

PUT

PUT요청은 클라이언트가 서버에게 특정 자원을 업데이트하거나 생성할 때 사용한다. 중요한 점은 서버가 해당 자원을 그대로 업데이트하거나 생성하는데 사용해야 한다. PUT은 대상 자원의 URI를 명확히 알고 있을 때 사용되며, 해당 URI에 데이터를 업데이트합니다.

PUT과 PATHC의 가장 큰 차이점은 PUT 요청은 일괄 변경이지만, PATCH의 요청은 부분 변경이다.

PATCH

PATCH는 리소스의 부분적인 수정을 의미합니다. PUT이 전체 리소스를 교체하는 데 사용되는 반면, PATCH는 리소스의 일부분만을 수정합니다. 예를 들어, 블로그 포스트의 일부 내용을 수정하거나 사용자 정보 중에서 이메일 주소만 업데이트하는 경우에 PATCH를 사용할 수 있습니다. 따라서 PATCH는 PUT보다 세부적인 수정이 필요할 때 사용됩니다

 

HTTP Method 속성

멱등성

멱등성이란 같은 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미합니다. GET, PUT, PATCH, DELETE의 경우에는 먹등하다고 이야기할 수 있습니다. 하지만 post의 경우에는 멱등하지 않습니다.

 

그 예시로 주문 처리 프로세스를 수행한다고 가정했을 때 사용자가 결제 요청을 post로 보내면 처음은 수행되겠지만, 다시 한번 더 보내게 된다면 중복결제로 서버에서 막을 것임으로 결과가 달라지기 때문입니다.

 

멱등성이 중요한 이유는 자동복구 매커니즘에 활용될 수 있기 때문입니다. client가 멱등성을 보장하는 http method를 요청했고, 서버에서 응답이 없었다면, client는 다시 한번 시도해도 서버에 오류가 발생하지 않기 때문입니다.

안전

resource의 변경이 없을 경우에는 안전한 메서드라고 이야기합니다. 멱등성과의 차이점은 resource의 변경유무입니다. 

안전성을 제공하는 method는 GET요청이 유일합니다.

 

왜 GET요청만이 안전한 이유는 GET의 경우에는 자원의 조회만 하기 때문입니다. 멱등성을 보장하는 METHOD들은 자원을 직접적으로 변경하지만 결과는 같기 때문입니다.

캐시가능성

캐시 가능성은 특정 HTTP 메서드의 요청의 결과가 캐시가 될 수 있는지 여부를 나타냅니다. GET, HEAD, POST, PATCH가 캐시 가능 여부를 지원하지만 실제로 사용되는 것은 GET과 HEAD입니다. POST와 PATCH의 경우에는 본문 내용을 캐시로 만드는 것이 쉽지 않기 때문에 대부분 지원하지 않습니다.

 

HTTP status

클라이언트가 요청한 내용의 결과를 알려주기 위해서 사용됩니다. 많은 status code가 존재하기 때문에 client는 상위 코드가 어떤 것을 뜻하는지 알아야 합니다.

 

1xx

"Client가 요청한 응답을 서버에서 처리중이다"를 알려주는 상태코드입니다. 실제론 사용되지 않고 있습니다.

2xx

2번대의 상태코드는 client가 보낸 요청을 성공적으로 처리했다는 것을 알려주기 위해서 사용됩니다.

 

200 Ok

제일 일반적인 상태로 client의 요청이 처리됐다는 것을 의미합니다.

 

201 Created

Client가 POST요청을 보내면 서버에서 리소스 생성이 완료됐다고 알려주는 상태코드입니다. Location의 header에는 사용자가 요청한 리소스가 어디에 저장되어 있는지 전달해 줍니다.

 

202 Accepted

Accept는 클라이언트의 요청이 서버에서 수락되었지만 아직 처리되지 않았음을 의미합니다. 이 상태코드는 보통 작업을 예약할 때  많이 사용되지만, 실제론 잘 사용되지 않습니다.

예를 들어, 대규모 파일 업로드를 비동기적으로 처리하는 경우, 서버는 요청을 수락했음을 알리기 위해 202 Accepted를 반환할 수 있습니다

 

204 No Content

서버가 요청을 성공적으로 처리했으며, 응답 본문(payload body)에 추가로 보낼 내용이 없음을 나타냅니다. 보통은 Delete 요청을 수행한 후 이 응답코드를 사용합니다.

 

이 외에도 서버에서 클라이언트의 요청을 성공적으로 처리했지만 응답 본문에 보낼 데이터가 전혀 필요 없다고 판단될 때 204 상태 코드를 사용할 수 있습니다

 

3xx

client의 요청을 완료하려면 추가적인 행동이 필요할 때 사용하는 상태코드입니다. redirection에는 영구, 일시 특수 리다이렉션이 있습니다.

 

301 Moved Permanently, 308 Permanent Redirect - 영구 리다이렉션

301과 308은 리소스의 URI가 영구적으로 변경됐다는 것을 의미합니다. 

301의 경우에는 리다이렉션 시 GET요청으로 변경되며 body가 제거됩니다. 

308의 경우에는 리다이렉션 시 최초 요청 method가 유지되게 됩니다.

 

이 두 메서드는 잘 사용되지 않습니다.

 

302 Found, 303 See Other, 307 Temporary Redirect - 일시 리다이렉션

리소스의 URI가 일시적으로 변경됐을 경우에 사용됩니다.

302의 경우에는 301 행동은 똑같습니다. 다만 resource가 영구적으로 이동했냐, 일시적으로 이동했냐의 차이점이 있습니다.

303의 경우에는 리다이렉션시 HTTP METHOD는 반드시 GET 요청으로 변환됩니다.

307의 경우에는 308과 비슷합니다. 역시 일적인 URI가 일시적인 이유입니다.

 

304 Not Modified - 특수 리다이렉션

리소스의 캐싱을 위해서 사용됩니다. 

이 동작은 특정 리소스의 변경 유무를 감지하기 위해서 사용됩니다. 응답 패킷에 body가 없고, 헤더에 Date, ETag, Last-Modified와 같은 헤더가 포함됩니다

작동 원리:

1. 조건부 요청: 클라이언트가 리소스를 요청할 때 If-Modified-Since 또는 If-None-Match 헤더를 포함시킬 수 있습니다. 이 헤더는 클라이언트가 가지고 있는 리소스의 버전 정보를 담고 있습니다.
2. 서버 확인: 서버는 제공된 타임스탬프(If-Modified-Since) 또는 ETag(If-None-Match)와 현재 리소스의 버전을 비교합니다.
3. 응답: 리소스가 수정되지 않은 경우, 서버는 304 상태 코드와 함께 응답 본문 없이 응답합니다. 리소스가 수정된 경우, 서버는 갱신된 리소스와 함께 200 OK 상태 코드로 응답합니다.

4xx

client 요청이 잘못됐을 경우에 서버에 400번대의 상태코드를 client에게 전송합니다 

 

400 Bad request

대표적으로 client가 spec에 맞지 않게 요청을 보냈거나, 파라미터 값이 정확하지 않을 때 응답하는 상태코드입니다.

 

401 Unauthorized

이 경우에는 인증이 수행되지 않았을 경우에 반환하는 상태코드입니다. 응답헤더에는 인증 방법을 Client에게 알려줘야 합니다.

예를 들어, 사용자 로그인이 필요한 페이지에 인증되지 않은 사용자가 접근할 때 반환될 수 있습니다

인증과 인가

인증은 로그인의 유무를 뜻하며, 인가는 특정 리소스에게 접근할 수 있는 권한이 있는지를 뜻하게 됩니다  

403 Forbidden

서버가 접근을 거부했다는 것을 알려줍니다. 이 부분은 주로 클라이언트는 인증되었지만, 권한이 없는 resource에 접근하려고 하면 나타납니다.

 

404 Not found

사용자가 잘못된 URI를 요청하면, 서버에서 전달하는 상태코드입니다.

 

5xx

서버에 에러가 발상한 경우에 응답하는 상태코드입니다.

 

500 Internal server error

요청한 서버에서 에러가 생겼다는 것을 의미합니다.

 

503 service unavailable

503 Service Unavailable는 서버가 과부하 상태이거나 유지보수 중일 때, 또는 일시적인 문제로 서비스를 제공할 수 없음을 나타냅니다. 예를 들어, 웹 서버가 과부하로 인해 요청을 처리할 수 없을 때 이 상태 코드를 반환할 수 있습니다.

4xx vs 5xx

400과 500의 주요 차이점은 복구 가능성입니다. 400의 경우 client 쪽에서 에러를 낸 것이기 때문에 똑같은 요청을 보내면 항상 똑같이 에러가 발생하게 됩니다. 하지만 500의 경우에는 서버 쪽 에러이기 때문에 서버가 복구되면 client 요청이 처리될 가능성이 있습니다.