HTTP 메서드
HTTP 메서드는 클라이언트가 서버에 원하는 동작을 지정하는데 사용한다.
각 메서드는 고유한 역할과 속성을 가진다.
GET 조회
POST 생성(등록)
PUT 완전히 대체
PATCH 부분적으로 수정
DELETE 삭제
주요 HTTP 메서드
1. GET
서버의 리소스를 조회하는 데 사용한다.
데이터를 쿼리 파라미터를 통해 전달하며, 메시지 본문 사용은 권장하지 않는다.
2. POST
새로운 리소스를 생성(등록)하거나, 서버에 데이터를 처리하도록 요청하는 데 사용한다.
요청 데이터를 메시지 본문에 담아 서버로 보낸다.
3. PUT
특정 위치의 리소스를 완전히 대체한다.
만약 리소스가 존재하지 않으면 새로 생성한다.
4. PATCH
리소스의 일부를 부분적으로 수정할 때 사용한다.
5. DELETE
특정 리소스를 삭제하는 데 사용한다.
HTTP 메서드의 속성
메서드는 안전성, 멱등성, 캐시 가능성이라는 중요한 속성을 가진다.
1. 안전(Safe)
메서드를 호출해도 리소스가 변경되지 않는 속성이다.
GET, HEAD는 안전한 메서드이다. 여러 번 호출해도 서버의 상태에 영향을 주지 않는다.
2. 멱등(Idempotent)
동일한 요청을 여러 번 보내도 결과가 항상 동일한 속성이다.
⭕️ 멱등 메서드: GET, PUT, DELETE
GET: 한 번 조회하든 여러 번 조회하든 같은 결과를 반환한다.
PUT: 리소스를 덮어쓰므로 여러 번 실행해도 최종 상태는 같다.
DELETE: 리소스를 삭제한 후 다시 삭제를 요청해도 이미 삭제된 상태이므로 결과는 동일하다.
❌ 비멱등 메서드: POST
POST: 새로운 리소스를 계속 생성하기 떄문에 여러 번 호출하면 중복된 데이터가 생성될 수 있다.
3. 캐시 가능(Cacheable)
요청에 대한 응답 결과를 캐시하여 재사용할 수 있는 속성이다.
- 캐시 가능한 메서드: 주로 GET, HEAD
- 캐시 불가능한 메서드: POST, PATCH
이들은 요청 본문의 내용에 따라 결과가 달라질 수 있어 캐시하기 어렵다.
HTTP 상태코드
클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능
1.xx 요청이 수신되어 처리중
2.xx 요청 정상 처리
3.xx 요청을 완료하려면 추가 행동이 필요
4.xx 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5.xx 서버 오류, 서버가 정상 요청을 처리하지 못함
2.xx - 성공(Success)
200 OK
가장 일반적인 성공 상태 코드로, 클라이언트의 요청이 성공적으로 처리되었음을 의미한다.
서버는 요청된 리소스와 함께 응답 본문을 보낸다.
201 Created
요청이 성공적으로 처리되어 새로운 리소스가 생성되었을 때 반환된다.
주로 POST 요청을 통해 새로운 데이터를 생성하는 API에서 사용된다.
서버는 응답 헤더의 Location 필드에 새로 생성된 리소스의 URI를 포함하여 클라이언트가 해당 리소스에 접근할 수 있도록 정보를 제공하는 것이 일반적이다.
202 Accepted
요청이 성공적으로 접수되었지만 아직 처리가 완료되지 않았음을 나타낸다.
이는 서버가 요청을 즉시 처리할 수 없거나, 백그라운드에서 오랜 시간이 소요되는 작업을 비동기적으로 처리할 때 사용된다.
204 No Content
요청은 성공적으로 처리되었지만, 클라이언트에게 돌려줄 응답 본문 데이터가 없을 때 사용된다.
이 코드는 주로 DELETE 요청이나 PUT 요청처럼 클라이언트가 특정 동작의 성공 여부만 알면 되는 경우에 유용하다. 브라우저는 204 응답을 받으면 페이지를 새로 고치거나 다른 페이지로 이동하지 않는다.
3.xx - 리다이렉션 Redirection
클라이언트가 요청을 완료하기 위해 추가적인 조치를 취해야 함을 의미한다.
서버는 3xx 응답과 함께 Location 헤더에 새로운 URL을 포함시켜 클라이언트가 자동으로 해당 위치로 이동하도록 지시한다.
영구 리다이렉션 - 301, 308
리소스의 URL이 영구적으로 변경되었음을 클라이언트에게 알려주는 HTTP 응답이다.
이 방식은 검색 엔진 최적화(SEO)에 매우 중요한데, 이전 URL의 링크 가치를 새로운 URL로 온전히 이전 시킬 수 있기 때문이다.
301 Moved Permanently
301은 가장 보편적인 영구 리다이렉션 코드이다.
대부분의 클라이언트는 이 코드를 받으면 새로운 URL로 이동한다.
중요한 특징은 POST 요청이 리다이렉션되면 GET 요청으로 바뀔 수 있다.
즉, 사용자가 폼 데이터를 POST로 전송했는데 301 리다이렉트가 발생하면,
브라우저가 새 URL로 데이터를 다시 보내지 않고 단순히 GET 요청을 보낼 가능성이 있다.
이로 인해 원래의 요청 데이터가 손실될 수 있다.
308 Permanent Redirect
308은 301과 기능적으로 동일하지만, 중요한 차이점이 있다.
리다이렉션 시 요청 메서드와 본문을 그대로 유지한다.
예를 들어, 클라이언트가 POST 요청을 보냈을 때 308 응답을 받으면,
클라이언트는 새 URL로 동일한 POST 요청과 본문 데이터를 다시 보낸다.
따라서 HTTP에서 HTTPS로의 전환이나 API 엔드포인트 변경처럼 요청 메서드와 본문 데이터가 반드시 유지되어야 하는 상황에 더 적합하다.
일시 리다이렉션 - 302, 307, 303
리소스의 URI가 일시적으로 변경, 따라서 검색 엔진 등에서 URL을 변경하면 안됨
리소스의 URL이 잠시 다른 곳에 위치함을 알리는 데 사용된다.
영구 리다이렉션과 달리, 검색 엔진은 원래의 URL이 곧 다시 사용될 것으로 판단하므로 URL을 변경하거나 링크 가치를 이전하지 않는다.
302 Found
- GET으로 변경될 수 있음(may)
- 가장 널리 쓰이는 기본값. POST 요청 후 리다이렉트 시 GET으로 변환될 가능성이 있음.
307 Temparay Redirect
- 메서드 유지(must not)
- 302와 기능은 같지만, 요청 메서드를 반드시 유지해야할 때 사용
303 See Other
- GET으로 변경(always)
- 리다이렉트 시 반드시 GET으로 전환해야 할 때 사용한다
- POST 요청 후 GET으로 결과 페이지를 보여줄 때 유용
현실적으로는 많은 오래된 라이브러리나 프레임워크가 302를 기본 리다이렉션 코드로 사용하고 있어,
메서드 변경이 문제가 되지 않는 경우에는 여전히 널리 사용되고 있다.
그러나 명확한 의미 전달과 안정적인 동작을 위해서는 307이나 303을 사용하는 것이 권장된다.
PRG(Post/Redirect/Get) 패턴
PRG 패턴은 웹 애플리케이션에서 중복 제출 문제를 방지하기 위한 핵심적인 디자인 패턴이다.
- POST: 클라이언트가 폼 데이터를 POST 요청으로 서버에 보낸다(주문, 게시글 작성)
- Redirect: 서버는 데이터 처리가 성공적으로 완료되면, 응답으로 303 See Other 상태코드를 보내고 Location 헤더에 결과 페이지의 URL을 담는다.
- GET: 브라우저는 리다이렉션 응답을 받고, Location 헤더의 URL로 새로운 GET 요청을 보낸다.
이 요청은 단순히 결과 페이지를 조회하는 역할을 한다.
사용자가 결과 페이지에서 새로고침을 하더라도,
이미 URL이 POST에서 GET으로 바뀌었기 때문에 새로운 GET 요청만 다시 발생한다.
이는 서버에 데이터 처리 요청(POST)을 다시 보내는 것이 아니므로
중복 주문이나 중복 게시글 작성과 같은 문제를 효과적으로 방지한다.
4.xx - 클라이언트 오류(Client Error)
서버가 클라이언트의 요청을 처리할 수 없을 때 발생한다.
이는 클라이언트의 요청 자체에 문법적 오류가 있거나, 유효하지 않은 데이터가 포함되어 있기 때문이다.
서버는 요청이 잘못되었음을 명확히 알려주므로, 클라이언트는 오류의 원인을 파악하고 요청 내용을 수정한 뒤 다시 시도해야 한다. 같은 요청을 그대로 재시도하면 실패할 확률이 높다.
400 Bad Request
요청의 구문이 잘못되었거나 메세지가 유효하지 않아 서버가 요청을 이해할 수 없을 때 발생한다.
예를 들어, 필수 요청 파라미터가 누락되었거나, JSON 데이터 형식이 잘못되었을 때 이 코드를 반환한다.
클라이언트는 요청 내용을 꼼꼼히 다시 확인해야 한다.
401 Unauthorized
클라이언트가 해당 리소스에 접근하기 위해 인증(Authentication)이 필요함을 의미한다.
즉, 로그인이 되지 않았거나 유효하지 않은 인증 정보를 보냈을 때 발생한다.
서버는 보통 응답 헤더에 WWW-Authenticate 필드를 포함하여 클라이언트에게 어떤 방식으로 인증해야 하는지 알려준다.
"Unauthorized"라는 용어 때문에 인가(Authorization) 오류로 오해하기 쉽지만, 사실은 인증(Authentication) 오류이다.
403 Forbidden
서버가 클라이언트의 요청을 이해했지만, 해당 리소스에 접근할 권한이 없으므로 요청을 거부할 때 발생한다.
클라이언트는 이미 인증(로그인)되었지만, 리소스에 대한 인가(Authentication)가 부족한 경우이다.
예를 들어, 일반 사용자가 관리자 전용 페이지에 접근하려 할 때 이 오류가 발생할 수 있다.
404 Not Found
요청된 리소스를 서버에서 찾을 수 없을 때 반환되는 가장 흔한 오류 코드이다.
URL이 잘못되었거나, 리소스가 삭제되었을 때 발생한다.
때로는 서버가 특정 리소스의 존재를 숨기기 위해, 권한이 없는 클라이언트에게 403 대신 404를 반환하기도 한다.
5.xx 서버 오류(Server Error)
서버 자체의 문제로 인해 요청을 처리할 수 없을 때 발생한다.
클라이언트의 요청은 유효했지만, 서버에서 예상치 못한 오류가 발생했기 때문이다.
이 경우 클라이언트가 같은 요청을 다시 시도하면 서버 문제가 해결되어 성공할 수도 있다.
500 Internal Server Error
가장 일반적인 서버 오류 코드이다.
서버가 요청을 처리하는 과정에서 예상치 못한 내부 오류가 발생했을 때 사용된다.
개발자가 미처 예상하지 못한 버그, 잘못된 설정, 데이터베이스 문제 등이 원인이 될 수 있다.
이 코드는 서버가 더 구체적인 오류 원인을 설명할 수 없을 때 포괄적으로 사용된다.
503 Service Unavailable
서버가 현재 요청을 처리할 수 없는 상태임을 나타낸다.
이는 보통 서버의 일시적인 과부하나 계획된 서버 점검 때문에 발생한다.
서버는 Retry-After 헤더를 함께 보내 클라이언트에게 얼마 후에 다시 요청을 시도해야 하는지 알려줄 수 있다.
이 코드는 클라이언트에게 서버의 문제가 일시적이며 곧 해결될 것임을 전달하는 데 유용하다.
이미지 출처: 인프런, 모든 개발자를 위한 HTTP 웹 기본 지식, 김영한
