✒️ 0. 들어가기 전
계속 포스팅에서 HTTP에 대한 깊게 알아보았다.
이번에는 간단하게, HTTP 상태코드와 HTTP 메서드에 대해 짧게 알아보겠다.
✒️ 1. 많이 사용되는 HTTP 상태코드(status code)
HTTP 상태코드는 서버가 클라이언트의 요청에 대한 처리 결과를 나타내는 3자리 숫자이다.
사실, 아래 소개하는 상태 코드 말고도 정말 많은 상태코드가 있다.
또한, 실제 HTTP 상태를 디테일하게 쪼개지 않고 프런트측과 약속하여 일부 포괄적으로 사용하거나
역으로 좀 더 디테일하게 상태코드를 설정하여 에러메시지와 함께 바디에 보내기도 한다.
혹은 성공 Status는 따로 구분하지 않고 200으로 통일하는 경우도 있다.
[즉, 상황에 따라 어떤 Status를 보내줄 지는 프런트와 약속하여 정하기 나름]
💡 1xx (정보)
요청이 수신되어 처리 중임을 나타낸다.
- 100 (Continue): 계속 진행함을 의미한다.
💡 2xx (성공)
요청이 성공적으로 처리되었음을 나타낸다.
- 200 (OK): 요청이 성공적으로 처리되었다.
- 201 (Created): 요청이 성공적으로 처리되어 새로운 리소스가 생성되었다.
💡 3xx (리다이렉션)
요청 완료를 위해 추가 작업이 필요함을 나타낸다.
- 301 (Moved Permanently): 요청한 리소스의 URI가 영구적으로 변경되었다.
💡 4xx (클라이언트 오류)
클라이언트의 요청에 오류가 있음을 나타낸다.
- 400 (Bad Request): 서버가 클라이언트의 요청을 이해할 수 없다.
- 401 (Unauthorized): 클라이언트가 인증되지 않았다.
- 404 (Not Found): 요청한 리소스를 찾을 수 없다.
가장 흔한 것은 요청한 리소스(페이지) 등을 찾을 수 없을 때 이다.
CS 내용의 여담이지만,
실무나 프로젝트를 할 때, 예외 처리 / 404 NotFound 페이지도 구성 등.
항상 꼼꼼하고 사용자 친화적인 코딩을 하도록 명심하자.
💡 5xx (서버 오류)
서버에서 요청을 처리하지 못했음을 나타낸다.
- 500 (Internal Server Error): 서버에 내부 오류가 발생했다.
- 502 (Bad Gateway): 게이트웨이 또는 프록시 서버에 오류가 발생했다.
- 504 (Gateway Timeout): 게이트웨이 또는 프록시 서버가 정해진 시간 내에 응답을 받지 못했다.
✒️ 2. 주요 HTTP 메서드
HTTP 메서드는 클라이언트가 서버에 요청하는 동작의 종류를 나타낸다.
사실, 우리가 사용하는 GET, POST, PUT, DELETE, PATCH 말고도 여러가지가 있지만,
우리는 이 중에서 자주 쓰이는 HTTP 메서드만 살펴보겠다.
- GET
- POST
- PUT
- HEAD
- DELETE
- PATCH
- OPTIONS
- CONNECT
- TRACE
💡 GET: 리소스를 조회한다.
- URL을 통해 데이터를 요청한다.
- 데이터 길이에 제한이 있다(일반적으로 2000자 미만).
- 캐싱이 가능하다.
- 브라우저 히스토리에 남는다.
- 민감한 정보 전송에는 적합하지 않다.
💡 POST: 새로운 리소스를 생성한다.
- HTTP 메시지 본문(body)을 통해 데이터를 전송한다.
- 데이터 길이에 제한이 없다.
- 캐싱이 불가능하다.
- 브라우저 히스토리에 남지 않는다.
- 모든 유형의 데이터를 전송할 수 있다.
- 민감한 정보 전송에 적합하다.
💡 PUT: 리소스를 완전히 대체한다.
- 대상 리소스의 모든 현재 표현을 요청 payload로 대체한다.
- 리소스가 없으면 새로 생성한다.
💡 PATCH: 리소스를 부분적으로 수정한다.
- 리소스의 일부분만 수정한다.
- PUT과 달리 전체를 대체하지 않고 지정된 부분만 변경한다.
💡 DELETE: 리소스를 삭제한다.
- 지정된 리소스를 서버에서 제거한다.
- 성공적으로 삭제되면 대개 204 (No Content) 상태 코드를 반환한다.
- PUT과 마찬가지로 멱등성을 가진다.
>> 민감한 정보 같은 것은 url에 노출시키지 말고 POST메서드로 body로 전달하는 것이 좋습니다. 어차피 패킷분석을 하게 되면 body에 있는 내용도 탐색할 수 있지만 1차적으로 보호하는 효과를 갖게 됩니다. 따라서 회원가입이나 로그인 같은 민감한 정보를 다룰 때는 POST를 사용해야 하는 것이죠.
✒️ 3. PUT과 PATCH의 주요 차이점
HTTP 메서드 중 PUT과 PATCH는 둘 다 데이터를 수정할 때 사용하는 메서드다.
그러나 다음과 같은 중요한 차이가 있다.
PUT은 업데이트하는 데이터의 전체를 보낸다.
요청을 보낼 때 해당 데이터 전체를 보내야 하고 전체 데이터의 교체를 의미한다.
PUT은 만약 해당 데이터가 없다면 새로이 생성하고, 있다면 요청할 때 보낸 데이터와 교체를 진행한다.
예: '{"a" : 1, "b" : 2}'가 있을 때 b를 3으로 바꾼다면 PUT의 경우 '{"a" : 1, "b" : 3}'으로 전체 데이터를 보내야 한다.
PATCH은 업데이트하는 데이터의 일부를 보낸다.
요청을 보낼 때 수정하는 일부분만 보내면 되고 일부분의 교체를 의미한다.
예: '{"a" : 1, "b" : 2}'가 있을 때 b를 3으로 바꾼다면 PATCH는 '{"b" : 3}' 이런 식으로 부분적으로 보내는 것을 말한다.
이러한 HTTP 상태코드와 메서드의 이해는 웹 개발과 API 설계에 필수적이다.
각 상황에 적절한 상태코드와 메서드를 사용함으로써 명확하고 효율적인 통신이 가능해진다.
추가적으로 이전에 프로젝트 도중에 썼던 포스팅이 있어서 글 남겨본다.
PUT vs PATCH !? 일부 수정하고싶어... (Boolean, Optional, JsonNullable, MapStruct)
1. 사건의 발단날씨 앱을 만드는 과정에서사용자가 설정창에서 ON 해놓은 정보들만 메인 화면에 띄울 수 있는 기능이 있다. 그래서 dto를 이렇게 잡고 시작했다.public record DisplayDto( boolean precipitati
jinhos-devlog.tistory.com
📝 면접 예상 질문
질문 + 간단한 답(구체적으로 대답하는 연습을 하자)
HTTP 상태코드 그룹: 1xx: 정보 응답, 2xx: 성공, 3xx: 리다이렉션, 4xx: 클라이언트 오류, 5xx: 서버 오류
GET vs POST: GET은 데이터 조회, URL에 노출. POST는 데이터 제출, 본문에 포함.
PUT vs PATCH: PUT은 리소스 전체 교체, PATCH는 부분 수정.
401 vs 403: 401은 인증 필요, 403은 인증됐으나 권한 없음.
RESTful API 메서드 선택 중요성: 리소스에 대한 의도를 명확히 표현, API 이해도와 사용성 향상.
GET vs POST 캐싱: GET은 캐싱 가능, POST는 일반적으로 불가능.
300번대 상태 코드: 리소스 위치 변경 알림. 주요 종류: 301(영구 이동), 302(임시 이동), 304(수정되지 않음).
멱등성: 여러 번 호출해도 결과 동일. GET, PUT, DELETE는 멱등, POST는 비멱등.
