[Net] HTTP Method

JABHACK 2024. 11. 30. 15:45

2024. 11. 30. 15:45

HTTP Method

📌 클라이언트 - 서버 사이에 이루어지는 요청, 응답 데이터를 전송하는 방식을 뜻한다.

[1] POST

리소스 생성
요청 데이터 처리, 메시지 바디를 통해 서버로 요청 데이터 전달
요청 데이터 처리 방식은 요청마다 다르므로 여기가 코딩하는 부분
메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

POST 요청 데이터를 어떻게 처리한다는 뜻일까?

예시

• 스펙: POST 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청합니다. (구글 번역)

• 예를 들어 POST는 다음과 같은 기능에 사용됩니다.

• HTML 양식에 입력 된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공

예) HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용

• 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시

예) 게시판 글쓰기, 댓글 달기

• 서버가 아직 식별하지 않은 새 리소스 생성

예) 신규 주문 생성

• 기존 자원에 데이터 추가

예) 한 문서 끝에 내용 추가하기

• 정리: 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 -> 정해진 것이 없음

클라 요청 - 서버 신규 Resource 생성 - 응답
주로 HTML FORM(회원가입, 게시글 작성 등)에 사용된다.
요청 데이터를 처리하는 방식에 정해진것은 없다.
1. 요청 데이터 처리(로그인 등)에 사용한다.
2. 조회시 JSON 요청 데이터가 필요한 경우에도 사용될 수 있다.
Message Body를 통해 요청 데이터를 전달한다.

정리

1. 새 리소스 생성(등록)

• 서버가 아직 식별하지 않은 새 리소스 생성

2. 요청 데이터 처리

• 단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우

• 예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우

• POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음

• 예) POST /orders/{orderId}/start-delivery (컨트롤 URI)

3. 다른 메서드로 처리하기 애매한 경우

• 예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

• 애매하면 POST

[2] GET

리소스 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

1. Query String 미포함하는 경우

GET의 경우 Message Body가 지원되지 않는 경우가 많아 권장하지 않는다.

2. Query String 포함하는 경우

서버에 추가적인 데이터 전송을 해야한다면, Message Body가 아닌 Query String(Query Parameter)를 사용한다.

[3] PUT

리소스 덮어쓰기, 없으면 생성도 함
POST와는 다르게 클라이언트 측에서 리소스를 식별하여 URI를 지정한다.

1. 기존 리소스가 존재하는 경우

2. 기존 리소스가 존재하고 일부만 변경하는 경우 중요!

기존 리소스가 존재하면 완전히 덮어쓰기가 된다.

3. 기존 리소스가 없는 경우

[4] PATCH

리소스 부분 수정

[5] DELETE

리소스 삭제

[6] 기타 Method

HEAD
- GET에서 Message Body를 제외하고 상태 줄과 헤더만 반환한다.
OPTIONS
- 대상 리소스에 대한 통신 가능한 Method를 설명한다.
CONNECT
- 대상 자원으로 식별되는 서버에 대한 터널을 설정한다.
- 잘 사용하지 않는다.
TRACE
- 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행한다.
- 잘 사용하지 않는다.

메서드	설명	배달에 비유한 예시	용도	예
GET	서버에서 데이터를 조회하는 메서드	배달된 상품을 조회하는 과정: "배달 상태를 확인하기 위해 배달업체에 연락"	데이터를 가져오기 위한 요청 (예: 웹 페이지 조회)	GET /index.html HTTP/1.1
POST	서버에 데이터를 보내는 메서드	새로운 상품 주문하기: "새로운 피자를 주문하여 배달을 요청"	데이터를 서버에 제출하거나 생성 (예: 새 사용자 등록)	POST /users HTTP/1.1
PUT	서버의 기존 데이터를 수정하거나 새 데이터를 생성하는 메서드	기존 주문 수정하기: "기존 주문한 피자 크기를 바꾸거나 새로 주문"	데이터 업데이트 또는 생성 (예: 기존 정보를 수정하거나 새로운 리소스를 추가)	PUT /users/1 HTTP/1.1
DELETE	서버의 데이터를 삭제하는 메서드	배달된 상품 취소하기: "이미 주문한 피자를 취소하고 배달을 중지"	리소스를 삭제 (예: 사용자 계정 삭제)	DELETE /users/1 HTTP/1.1
HEAD	GET과 유사하지만, 응답 본문을 제외한 헤더만 반환하는 메서드	배달의 세부 사항만 확인: "배달된 상품이 무엇인지, 배달 상태를 확인"	헤더만 조회하고 본문을 무시 (예: 서버의 메타데이터 확인)	HEAD /index.html HTTP/1.1
OPTIONS	서버가 지원하는 HTTP 메서드 목록을 반환하는 메서드	배달 가능한 옵션 확인: "어떤 상품이 가능한지, 또는 선택 가능한 배달 방법이 무엇인지 확인"	서버가 지원하는 메서드 및 기능을 확인 (예: 서버 기능 검사)	OPTIONS /users HTTP/1.1
PATCH	리소스의 일부를 수정하는 메서드	부분 주문 수정: "피자의 일부만 수정해서 추가 주문"	리소스의 일부만 수정 (예: 사용자 정보 일부 수정)	PATCH /users/1 HTTP/1.1
TRACE	요청이 서버에 도달하기까지의 경로를 추적하는 메서드	배달 경로 추적: "주문이 어떻게 배송되는지 확인하기 위해 배달업체에 문의"	요청 경로 추적 (예: 디버깅용, 요청이 서버에 어떻게 도달했는지 확인)	TRACE / HTTP/1.1
CONNECT	터널을 설정하여 클라이언트와 서버 간에 데이터를 전달하는 메서드	배달 중간에 통로 연결: "배달을 위한 안전한 경로를 설정"	프록시 서버를 통한 보안 연결 설정 (예: SSL 연결을 위한 터널링)	CONNECT www.example.com:443 HTTP/1.1

HTTP Method 속성

📌 HTTP Method는 안전성(Safe), 멱등성(Idempotent), 캐시가능성(Cacheable) 속성을 가지고 있다. 각각의 속성이 무엇인지와 어떤 HTTP Method가 해당 특성을 가지고 있는지 알아보자.

HTTP Method별 속성표

사진출처 : https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

Optional은 Java의 Optional과 같이 있을 수 있다라는 말과 같다.

[1] 안전성(Safe)

호출해도 리소스를 변경하지 않는다.

• Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면요?

• A: 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다

GET 메소드(조회)는 안전하다.
- 저장된 데이터를 변환하지 않는다.
POST, DELETE, PUT, PATCH는 안전하지 않다.
- 데이터를 생성, 수정, 삭제한다.

[2] 멱등성(Idempotent)

한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다.
1. GET → 같은 결과가 계속 조회된다.
2. PUT → 수정해서 대체된 후의 결과는 계속 같다.
3. DELETE → 같은 요청을 여러번해도 삭제된 결과는 같다.
4. POST → 멱등성을 보장하지 않는다.
ex) 계좌 송금을 두번한다면?, 게시판 글쓰기, 회원가입
요청이 실패한 경우 재시도 하기위해 필요하다.
1. 항상 결과가 같다면 마음껏 재시도 해도된다.
2. 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다.
3. 복구 매커니즘에 사용한다.
ex) 요청 실패시 서버에서 자동으로 재시도
리소스 조회(GET Method) 재요청 중간에 변경된다면?

재요청 중간에 리소스가 변경되는것은 멱등성으로 고려하지 않는다.

ex) 도서관 책 재고 조회(실시간으로 대여 혹은 판매됨)

[3] 캐시가능성 (Cacheable)

HTTP 메서드와 캐싱 가능성

HTTP 캐싱은 서버 응답을 클라이언트(브라우저)나 중간 캐시 서버에 저장하여, 동일한 요청에 대해 다시 서버와 통신하지 않고도 응답을 재사용할 수 있게 하는 기능입니다.
캐시 가능성은 특정 HTTP 메서드가 반환하는 응답이 캐시에 저장될 수 있는지 여부를 나타냅니다.

HTTP 메서드와 캐싱

GET
- 캐시 가능하며, 주로 정적 자원(HTML, CSS, JS, 이미지 등)에 사용됩니다.
- 변경 가능성이 적은 데이터를 효율적으로 제공하기 위해 캐시가 널리 사용됩니다.
HEAD
- 캐시 가능하며, GET 메서드와 유사하게 작동하지만 응답 본문 없이 헤더만 반환합니다.
- 응답 본문이 없으므로 캐시를 검증하거나 메타데이터를 요청하는 데 적합합니다.
POST
- 일반적으로 캐싱하지 않음.
- POST는 데이터 생성 또는 서버 상태 변경 요청에 사용되므로, 캐싱이 의미 없는 경우가 많습니다.
- 다만, 명시적으로 캐싱이 허용된 경우(예: 특정 API)에는 캐싱이 가능합니다.
- GET은 서버로 데이터를 불러오기만 하지만 POST는 요청 내용이 항상 다른데, 전의 요청 내용 답변을 캐시에 저장해 둬도, 다음 대답에서 해당 캐시를 사용하게 될지는 미지수이기 때문 = 캐시 시 의도하지 않은 동작을 하는 경우가 있음 [의도하지 않은 동작은 아래 접은 글 참조]

1. POST 요청 중복 처리

상황:

사용자가 POST 요청으로 서버에 데이터를 생성.
서버는 요청에 따라 새 주문을 생성하고, 성공 응답을 반환.

예시:

사용자가 상품을 주문:

POST /orders
Request Body: {"productId": 101, "quantity": 1}

서버는 새 주문을 생성하고 응답:

HTTP/1.1 200 OK
Response Body: {"orderId": 123, "status": "created"}

캐시 활성화로 인해 동일한 POST 요청이 캐시됨.
사용자가 동일한 요청을 다시 보냄:
- 브라우저나 네트워크 레벨에서 캐시된 응답을 반환.
- 그러나 실제로는 서버에서 새 주문이 생성되지 않았음.
결과:
- 사용자에게 잘못된 응답을 제공하거나,
- 의도치 않게 중복 주문이 발생.

2. 사용자 인증 토큰 갱신 실패

상황:

사용자가 POST 요청으로 인증 토큰을 갱신(refresh)하려고 함.
서버는 요청 시마다 새로운 토큰을 생성하여 반환.

예시:

사용자가 토큰 갱신 요청:
```
POST /auth/refresh
```

서버가 새 토큰 반환:

HTTP/1.1 200 OK
Response Body: {"token": "new-token-123"}

캐시가 응답을 저장.
사용자가 토큰 갱신 요청을 다시 보냄.
- 캐시된 응답이 반환되어 새 토큰이 아닌 이전 토큰을 사용.
결과:
- 토큰 만료로 인해 인증 실패.
- 사용자가 시스템에 접근 불가.

3. 결제 요청 중복 처리

상황:

사용자가 결제를 요청하여 서버가 거래를 처리.
서버는 POST 요청으로 결제 데이터를 받고 승인 응답을 반환.

예시:

사용자가 결제 요청:

POST /payments
Request Body: {"amount": 100, "method": "credit_card"}

서버가 결제를 처리하고 응답:

HTTP/1.1 200 OK
Response Body: {"transactionId": 456, "status": "approved"}

캐시가 POST 응답을 저장.
사용자가 동일한 요청을 재전송하거나 네트워크가 요청을 재시도:
- 서버가 요청을 중복 처리하여 결제가 두 번 이루어짐.
- 사용자가 의도치 않게 이중 결제를 하게 됨.

4. 회원가입 요청 중복 처리

상황:

사용자가 POST 요청으로 회원가입을 시도.
서버는 데이터를 저장하고 성공 응답 반환.

예시:

사용자가 회원가입 요청:

POST /users
Request Body: {"email": "user@example.com", "password": "secure"}

서버가 데이터를 저장하고 응답:

HTTP/1.1 201 Created
Response Body: {"userId": 789, "status": "registered"}

요청이 캐시됨.
사용자가 다시 요청을 보냄:
- 캐시된 응답이 반환되거나 서버가 요청을 중복 처리.
- 동일한 이메일로 중복 회원가입 발생.

5. 상품 재고 업데이트 오류

상황:

서버는 특정 상품의 재고를 업데이트하는 POST 요청을 처리.
재고는 매번 요청할 때 다른 값으로 업데이트되어야 함.

예시:

요청:

POST /inventory/update
Request Body: {"productId": 202, "quantity": 50}

서버가 재고를 업데이트:

HTTP/1.1 200 OK
Response Body: {"status": "updated"}

응답이 캐시됨.
동일한 요청 반복 시 캐시된 응답 반환:
- 재고 업데이트가 실패하거나,
- 이전 값으로 덮어써짐.

결론

POST 요청의 캐싱은 의도치 않은 동작을 초래할 가능성이 높음.
- 데이터 생성/수정 작업이 반복될 수 있음.
- 응답이 캐시되면 서버 상태와 클라이언트가 보관하는 데이터가 불일치할 수 있음.
GET 요청은 캐싱에 적합하지만, POST 요청은 신중하게 캐싱해야 함.
- POST 요청을 캐싱하려면 Cache-Control 헤더를 명시적으로 설정하고, 중복 요청 방지 로직을 추가해야 함.

Cache-Control 헤더는 HTTP/1.1에서 응답 및 요청의 캐싱 동작을 제어하기 위해 사용, 클라이언트(브라우저)와 중간 캐시 서버(프록시, CDN 등)가 리소스를 어떻게 캐싱하고 얼마나 오랫동안 유지해야 하는지에 대한 지침을 제공합니다.

캐싱의 일반적인 활용

캐싱 대상
- 변경 가능성이 적은 정적 자원:
  - HTML
  - CSS
  - JavaScript
  - 이미지 (JPG, PNG, GIF 등)
- API 응답 (GET 요청의 경우)
캐싱 설정
- HTTP 헤더를 통해 캐싱 동작을 제어:
  - Cache-Control: 캐시의 동작 방식을 명시.
  - ETag: 캐시된 리소스가 변경되었는지 확인.
  - Last-Modified: 리소스의 최종 수정 시간을 알려줌.

정리

GET, HEAD: 캐싱에 적합하며, 주로 정적 리소스를 대상으로 활용.
POST: 일반적으로 캐싱하지 않지만, 명시적으로 허용된 경우 예외적으로 캐싱 가능.
캐싱의 목적: 네트워크 부하 감소, 응답 시간 단축, 성능 최적화.

위와 같이 간결하게 정리된 내용으로 캐싱 가능성을 설명할 수 있습니다. 😊

캐싱 가능성(Cacheable)이란?

💡 캐시(Cache)란? 클라이언트가 서버에 한번 요청했던 데이터에 대해서 매번 요청할 때 마다 다시 전송할 필요가 없도록 웹 브라우저가 임시적으로 데이터를 보관하고 있는 장소이다.

HTTP 상태 코드

📌 HTTP 요청에 대한 처리 상태를 응답하는 코드로 Data를 함께 응답한다. Spring에서는 Response를 커스텀하여 의미있는 메세지를 만들어 사용하기도 한다. ex) 201 Created, Message: 회원 가입이 완료되었습니다!

1xx (Informational): 요청이 수신되어 처리중

2xx (Successful): 요청 정상 처리

3xx (Redirection): 요청을 완료하려면 추가 행동이 필요

4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음

5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

HTTP Response Message 구조

HTTP Status Code

[1] 1xx

요청 수신 후 처리중인 상태
잘 사용하지 않는다.

[2] 2xx

정상 처리 완료된 상태

202 Accepted

요청이 접수되었으나 처리가 완료되지 않았음

• 배치 처리 같은 곳에서 사용

• 예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함

204 No Content

서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

• 예) 웹 문서 편집기에서 save 버튼

• save 버튼의 결과로 아무 내용이 없어도 된다.

• save 버튼을 눌러도 같은 화면을 유지해야 한다.

• 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.

= "야 됐어" - "안됐는데" - "암튼 됨 ㅇㅇ" - "?"

리다이렉션

🐳 클라이언트가 요청한 URL이 다른 URL로 자동으로 변경되는 과정을 의미합니다. 주로 웹 서버나 애플리케이션에서 사용되며, 사용자가 원래 요청한 리소스의 위치가 변경되었을 때 이를 알려주기 위해 사용됩니다.

리다이렉션은 주로 HTTP 응답 코드와 함께 발생하며, 클라이언트(브라우저 등)는 새로운 URL로 요청을 자동으로 보내게 됩니다. 리다이렉션에는 여러 가지 유형이 있습니다.
웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)

리다이렉션 종류

• 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동

예) /members -> /users
예) /event -> /new-event

• 일시 리다이렉션 - 일시적인 변경

주문 완료 후 주문 내역 화면으로 이동
PRG: Post/Redirect/Get

• 특수 리다이렉션

결과 대신 캐시를 사용

[1] 리다이렉션 코드 종류

리다이렉션 응답 코드는 3xx로 시작하며, 대표적인 코드들은 다음과 같습니다.

상태 코드	설명	용도
301 Moved Permanently	요청한 리소스가 영구적으로 이동되었음을 의미	리소스의 위치가 변경되었고, 앞으로 해당 리소스를 새로운 URL에서 사용해야 한다는 것을 알려줌
302 Found (또는 Moved Temporarily)	요청한 리소스가 임시로 이동되었음을 의미	임시 리다이렉션, 리소스가 일시적으로 다른 URL로 이동한 경우 사용
303 See Other	요청한 리소스의 결과를 다른 URL에서 확인할 수 있음을 의미	POST 요청 후 리다이렉션 시 주로 사용 (예: 폼 제출 후 결과 페이지로 이동)
307 Temporary Redirect	302와 유사하지만, 메서드가 변경되지 않도록 유지	임시 리다이렉션, 원래의 HTTP 메서드(POST 등)가 그대로 사용되도록 보장
308 Permanent Redirect	301과 유사하지만, 메서드를 그대로 유지	영구적인 리다이렉션으로 원래의 HTTP 메서드를 그대로 사용

[2] 리다이렉션의 예시

리다이렉션은 일반적으로 웹 애플리케이션에서 URL을 변경하거나 리소스의 위치가 변경되었을 때 사용됩니다. 예를 들어:

301 Moved Permanently
- 사용자가 오래된 URL에 접근했을 때, 서버는 새로운 URL로 영구적으로 리다이렉트합니다.
- 예시: http://oldsite.com → http://newsite.com
302 Found
- 사용자가 특정 URL에 접근했을 때, 임시로 다른 URL로 이동시킵니다.
- 예시: http://example.com/login → http://example.com/maintenance
303 See Other
- 사용자가 폼을 제출한 후 결과 페이지로 리다이렉션하려면 303 상태 코드가 사용됩니다.
- 예시: 사용자 로그인 폼을 제출 후 결과를 보여주는 다른 페이지로 리다이렉션.
307 Temporary Redirect
- 임시 리다이렉션이지만, 메서드를 그대로 유지하려면 307 상태 코드를 사용합니다.
- 예시: 사용자가 POST 요청을 보낸 후 임시로 다른 페이지로 이동.

[3] 영구 리다이렉션

리소스의 URI가 영구적으로 이동
원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지
기존의 예전 URI로 접속해도 새로운 URI로 정상 접속된다.

301 Moved Permanently

리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

308 Permanent Redirect

301과 기능은 같음
리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

[4] 영구 리다이렉션

리소스의 URI가 일시적으로 변경
따라서 검색 엔진 등에서 URL을 변경하면 안됨

302 Found

리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

307 Temporary Redirect

302와 기능은 같음
리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)

303 See Other

302와 기능은 같음
리다이렉트시 요청 메서드가 GET으로 변경

그래서 뭘 써야 하나요?

잠깐 정리

• 302 Found -> GET으로 변할 수 있음

• 307 Temporary Redirect -> 메서드가 변하면 안됨

• 303 See Other -> 메서드가 GET으로 변경

역사

• 처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것

• 그런데 웹 브라우저들이 대부분 GET으로 바꾸어버림(일부는 다르게 동작)

• 그래서 모호한 302를 대신하는 명확한 307, 303이 등장함(301 대응으로 308도 등장)

현실

• 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용

• 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음

[5] 기타 리다이렉션

캐시를 활용할 것인지에 대한 여부
대표 상태코드
- 304 Not Modified
  - 캐시 목적으로 사용된다.
  - 리소스가 수정되지 않았다는 뜻, 클라이언트가 캐시된 데이터를 조회하도록 유도한다.
  - 응답에 바디가 있으면 안된다.

[6] 리다이렉션 배달에 비유

리다이렉션은 배달의 경로가 바뀌는 것과 비슷합니다. 예를 들어, 고객이 원래 주문한 피자 배달 경로가 변경되었을 때, 배달업체는 고객에게 "이제 다른 경로로 가야 한다"고 알려주고, 고객은 새로운 경로를 따라 가게 됩니다.
- 301 (영구적 이동): "이제부터 이 길로만 가세요! 영원히 이 길을 따라가세요."
- 302 (임시 이동): "이번에만 이 길로 가세요. 다음번엔 원래 길로 돌아가세요."
- 303 (다른 곳에서 확인): "주문을 끝내고 나서 다른 곳에서 결과를 확인하세요."
- 307 (임시 이동, 메서드 유지): "이 경로로 가긴 하지만, 원래 주문 방식을 그대로 유지하세요."

[4] 4xx

클라이언트측 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다.
클라이언트의 요청이 잘못되었기 때문에, 같은 요청의 재시도는 실패한다.
오류의 원인이 클라이언트에 있음

대표 상태코드
- 400 Bad Request
  - 요청 구문, 메시지 등등 오류
  - 클라이언트가 HTTP 요청 내용을 수정 후 보내야 한다.
  ex) GET 메소드로 만들어진 API인데 POST로 보낸다?
- ex) API 스펙과 일치하지 않을 때, 숫자를 문자로, 문자를 숫자로 등

- 401 Unauthorized
  - 클라이언트가 리소스에 대한 **인증(Authentication)**이 필요하다.
  - 인증(Authentication) 되지 않음
  - 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명한다.
  - 인증=누구세요 / 인가=권한있음?
  ex) 로그인
- 403 Forbidden
  - 서버가 요청을 받았지만 승인 거부
  - 주로 인가(Authorization) 관련문제
  ex) 일반 유저, 관리자
- 404 Not Found
  - 요청한 리소스가 서버에 없다.
  - 이를 이용하여 리소스를 숨겨놓기도 한다. 리소스가 있지만 없는척 하는 경우도 있다.

[5] 5xx

서버 오류, 요청은 정상이지만 서버가 처리하지 못함
재시도하면 성공할 수 있다.

ex) 서버가 일정시간 다운되었다가 다시 살아난 경우

실제 서버에서 문제가 발생한 경우 5xx Error이기 때문에 발생하지 않는것이 최선이다.
대표 상태코드
- 500 Internal Server Error
  - 대부분 500으로 처리한다.
- 503 Service Unavailable
  - 서비스 이용 불가
  - Retry-After Header를 사용하면 얼마뒤에 복구되는지 응답할 수 있다.

새로운 상태 코드가 추가되어도 변경할 필요가 없다.
디테일한 코드를 몰라도 몇 번대 코드인지만 알면 된다.
응답 코드를 상황에 맞게 잘 작성 해야 한다. 매우 기본이고 매우 중요하다.

저작자표시 비영리 동일조건

'CS ( Computer Science ) > 네트워크 (Networking)' 카테고리의 다른 글

[Net] HTTP 요청 데이터 (0)	2024.12.02
[Net] HTTP Header (0)	2024.12.01
[Net] HTTP (0)	2024.11.29
[Net] JSON (1)	2024.11.29
[Net] Web 기초 (1)	2024.11.29

잡학다식 개발일지