[HTTP] HTTP API 설계: HTTP 메서드와 상태 코드 완벽 가이드

웹 애플리케이션 아키텍처를 설계할 때 가장 기본이 되면서도 자주 간과되는 부분이 바로 HTTP 프로토콜의 표준 규약을 올바르게 준수하는 것이다. HTTP 메서드와 상태 코드는 단순히 클라이언트와 서버가 데이터를 주고받는 통로를 넘어, 전 세계 개발자들이 합의한 ‘웹의 약속(API Contract)’이다.

이 약속을 어기고 설계된 API는 가독성이 떨어질 뿐만 아니라, 브라우저 캐싱, 프록시 서버 최적화, 네트워크 장애 상황에서의 자동 복구 메커니즘 등 HTTP 인프라가 제공하는 강력한 혜택을 전혀 누릴 수 없게 된다.

이번 포스팅에서는 HTTP 주요 메서드의 동작 방식과 차이점, 안전(Safe)·멱등(Idempotent)·캐시가능(Cacheable) 속성의 실무적 의미, 그리고 1xx부터 5xx까지의 상태 코드가 가지는 프로토콜 수준의 설계 철학을 깊이 있게 파헤쳐 본다.

[Infra] 모든 것이 HTTP인 시대, 웹 통신의 근간 이해하기

 

 

1. HTTP 메서드의 종류와 핵심 역할

HTTP 메서드는 클라이언트가 서버에게 요청을 보낼 때 "이 리소스에 대해 어떤 행위(Verb)를 수행하길 원하는가"를 지시하는 도구다. 리소스를 명사(URI)로 정의하고, 행위를 동사(HTTP Method)로 분리하는 것이 REST 아키텍처 스타일의 핵심이다.

1.1 주요 HTTP 메서드 5종

메서드	주요역할	메시지 바디 사용 여부	데이터 전달 방식
GET	리소스 조회	권장하지 않음 (스펙상 가능하나 미지원 많음)	쿼리 파라미터 (Query String)
POST	요청 데이터 처리, 신규 리소스 등록	필수 및 적극 사용	메시지 바디 (JSON 등)
PUT	리소스 대체 (없으면 생성)	필수 및 적극 사용	메시지 바디 (전체 리소스)
PATCH	리소스 부분 변경	필수 및 적극 사용	메시지 바디 (변경할 필드)
DELETE	리소스 삭제	비권장 (필요 시 사용 가능)	주로 URI 경로 변수

 

① GET: 리소스 조회

• 서버의 데이터를 변경하지 않고 오직 조회할 때만 사용한다.
• 서버에 전달하고 싶은 데이터는 URI 뒤에 붙는 ?key=value 형태의 쿼리 파라미터(Query Parameter)를 통해 전달한다.
• 메시지 바디를 사용해 데이터를 보낼 수 있도록 정의한 RFC 스펙도 존재하지만, 실무에서는 방화벽, 프록시, 구형 WAS 등 호환성 문제로 인해 바디가 유실되거나 요청이 거절되는 경우가 많으므로 절대 권장하지 않는다.

② POST: 요청 데이터 처리 및 등록

• 메시지 바디를 통해 서버로 전송할 데이터를 전달한다.
• 단순히 데이터를 등록하는 것을 넘어, 서버 측에서 "요청 데이터를 처리하는 프로세스 전체"를 수행하는 만능 메서드다.
• 새로운 게시글 등록, 주문 처리, 결제 프로세스 시작, 회원가입 등 리소스의 상태 변화를 유발하는 핵심 행위에 쓰인다.

③ PUT: 리소스를 전체 대체

• 요청 경로(URI)에 지정된 리소스가 존재하면 해당 데이터를 완전히 덮어쓰고(대체), 리소스가 없다면 새롭게 생성한다.
• POST와의 결정적인 차이점: 클라이언트가 리소스의 구체적인 위치(ID 등 식별자)를 알고 URI를 직접 지정한다.
  • POST 예시: POST /members (서버가 ID를 새로 생성해서 등록하므로 구체적인 URI를 모름)
  • PUT 예시: PUT /members/100 (클라이언트가 100번 회원 자리를 완전히 대체하겠다고 지정함)
• 주의 사항: 만약 기존 리소스에 A, B라는 필드가 있었는데, PUT 요청 시 바디에 A 필드만 보내면 B 필드는 완전히 삭제되거나 디폴트 값으로 초기화된다. 리소스의 완전한 대체를 목표로 하기 때문이다.

④ PATCH: 리소스 부분 변경

• PUT이 전체 대체를 담당한다면, PATCH는 리소스의 일부 필드만 수정할 때 사용한다.
• 예를 들어, PATCH /members/100 요청 바디에 {"name": "새이름"}만 보낸다면 기존의 다른 필드(age, email 등)는 그대로 유지되고 name 필드만 업데이트된다.

⑤ DELETE: 리소스 삭제

• 지정한 URI에 위치한 리소스를 영구적으로 삭제한다.

 

1.2 기타 HTTP 메서드 4종

실무에서 자주 쓰이지는 않지만, 프레임워크 수준이나 대규모 분산 환경, 웹 보안 영역에서 필수적인 역할을 수행하는 메서드들이다.

• HEAD: GET과 완전히 동일하게 작동하지만, 서버는 메시지 바디를 제외하고 상태 줄과 헤더만 반환한다. 실제 대용량 데이터를 다운로드하기 전에 리소스의 크기(Content-Length)나 수정 시각(Last-Modified) 등을 빠르게 확인하여 네트워크 대역폭을 절약할 때 매우 유용하다.
• OPTIONS: 대상 리소스에 대해 허용되는 통신 옵션(지원하는 HTTP 메서드)을 질의한다. 주로 웹 브라우저가 다른 도메인의 자원에 접근할 때 보안성 검증을 위해 보내는 CORS(Cross-Origin Resource Sharing)의 Preflight(예비 요청) 단계에서 사용된다.
• CONNECT: 대상 리소스로 식별되는 서버에 대한 네트워크 터널을 설정한다. 주로 HTTPS 프록시 서버를 통과할 때 가상 커넥션을 맺기 위해 사용된다.
• TRACE: 루프백 테스트용 메서드로, 수신한 요청 메시지를 그대로 클라이언트에게 반환한다. 요청이 서버로 가는 도중 방화벽이나 프록시에 의해 헤더가 어떻게 변조되었는지 디버깅할 때 쓰인다. (보안 취약점 공격에 노출될 수 있어 실무에서는 대부분 차단해 둔다.)

 

 

2. HTTP 메서드의 핵심 속성: 안전, 멱등, 캐시가능

HTTP 명세(RFC 7231)는 메서드를 단순히 분류하는 것에 그치지 않고, 시스템 설계 시 의존해야 하는 세 가지 핵심 속성을 정의한다.

2.1 안전 (Safe Methods)

• 호출해도 서버의 리소스를 변경하지 않는 속성을 말한다.
• GET, HEAD, OPTIONS는 단순히 데이터를 조회하고 읽는 역할만 수행하므로 안전한 메서드에 속한다.
• POST, PUT, PATCH, DELETE는 서버의 내부 상태를 변경하기 때문에 안전하지 않은 메서드다.

 

2.2 멱등 (Idempotent Methods)

수학에서 멱등 연산은 f(f(x)) = f(x)를 만족하는 것을 뜻한다. 즉, 한 번 호출하든, 백 번 호출하든 리소스의 최종 상태가 동일하게 유지되는 속성이다.

• 멱등한 메서드:
  • GET: 여러 번 조회해도 데이터가 변하지 않으므로 언제나 결과가 같다.
  • PUT: 동일한 데이터로 리소스를 덮어쓰는 작업이므로 아무리 반복 요청해도 최종 결과는 동일하다.
  • DELETE: 삭제 요청을 처음 보냈을 때 리소스가 완전히 지워진다. 이후 같은 요청을 두 번, 세 번 보내면 비록 오류 응답(404 Not Found)이 돌아올지라도, 리소스가 "삭제된 최종 상태" 자체는 동일하게 유지된다.
• 멱등하지 않은 메서드:
  • POST: 두 번 호출하면 서버 내부적으로 동일한 비즈니스 프로세스가 중복 실행되어 새로운 주문 데이터가 2개 생성되거나, 결제가 두 번 발생하는 참사가 일어날 수 있다.
  • PATCH: 설계에 따라 다를 수 있으나 일반적으로 멱등하지 않은 경우가 많다. 예를 들어, "change_value": 30처럼 단순 값 변경은 멱등하지만, "add_age": 1처럼 증감 연산을 수행하도록 페이로드를 설계했다면 호출 횟수만큼 나이가 계속 늘어나므로 결과가 달라진다.

 

멱등성이 실무에서 가지는 강력한 의미: 자동 복구 메커니즘

서버 통신 중에 무선 통신 기지국 전환이나 서버 오버로드 등으로 타임아웃(Timeout)이 발생했다고 가정해 보자. 클라이언트는 "요청이 아예 전달이 안 된 것인지", "전달은 됐는데 응답만 못 받은 것인지" 전혀 알 수 없다.

이때 클라이언트가 자동 재시도(Retry)를 무지성으로 실행해도 안전할까?

• 멱등한 메서드(GET, PUT, DELETE)라면 안전하다. 실패 시 같은 요청을 다시 던지면 최종 상태는 정상 처리된 상태와 동일하기 때문에 클라이언트 엔진 수준에서 즉시 복구를 유도할 수 있다.
• 멱등하지 않은 메서드(POST)라면 절대 자동 재시도를 하면 안 된다. 사용자에게 "처리가 지연되고 있습니다" 혹은 "잠시 후 다시 시도해 주세요"라는 얼럿을 띄우거나, 백엔드에 사전에 발급받은 '멱등성 키(Idempotency Key)'를 심어서 요청의 고유성을 확인하는 애플리케이션 계층의 처리가 필수적이다.

 

2.3 캐시가능 (Cacheable Methods)

동일한 대용량 요청이 반복될 때, 서버 네트워크망을 타지 않고 브라우저나 프록시 캐시 장비에 응답 결과를 임시 보관해두고 사용하는 속성이다.

• 스펙상 GET, HEAD, POST, PATCH가 캐시 가능하다.
• 하지만 실무에서는 GET과 HEAD 정도만 캐시로 활용한다.
• 그 이유는 캐시 키(Cache Key) 설계 때문이다. HTTP 스펙상 캐시는 주로 요청 URI를 키로 삼는다. GET은 오직 URI만으로 동일한 응답이 보장되지만, POST와 PATCH는 복잡한 데이터가 들어있는 메시지 바디 내용까지 함께 파싱하여 캐시 키로 구현해야 하므로 표준 기술로 지원하기 극도로 까다롭고 효율이 떨어진다.

 

 

3. 클라이언트에서 서버로 데이터 전송 및 API 설계 패턴

데이터를 전송하는 기본 형태는 크게 2가지로 나뉜다.

1. 쿼리 파라미터(Query Parameter): 정렬, 검색 필터링 등 가벼운 조회 조건을 주로 GET 메서드와 조합해 사용한다.
2. 메시지 바디(Message Body): 회원 가입, 상품 등록 등 구조가 복잡하고 크기가 크며 보안 유지가 필요한 데이터 전송 시 POST, PUT, PATCH와 조합한다.

실무에서 가장 많이 만나는 API 설계의 4가지 상황을 살펴보자.

3.1 정적 데이터 조회 (Static Resource Collection)

• 이미지 파일, CSS 스타일시트, 단순 정적 HTML 및 텍스트 문서를 조회하는 경우다.
• 조회에 최적화된 GET을 사용한다.
• 정적 리소스는 특별한 조회 조건이 없기 때문에 /images/logo.png처럼 명확한 리소스 경로(Path)만 기술하여 가볍게 조회한다.

 

3.2 동적 데이터 조회 (Dynamic Data Query)

• 게시판의 키워드 검색, 특정 필터 기반 정렬(예: 최신순, 평점순) 시나리오다.
• 마찬가지로 조회이므로 GET을 사용하지만, 검색어와 정렬 조건 같은 매개변수들을 쿼리 파라미터를 활용해 전송한다.
• 예시: /search?q=jeonlog&sort=latest&limit=10
• 이를 통해 검색 결과 자체를 링크(URL) 형태로 다른 사람과 공유할 수 있어 웹 생태계의 접근성이 극대화된다.

 

3.3 HTML Form을 통한 데이터 전송

• 순수 HTML의 <form> 태그는 역사적인 한계로 인해 GET과 POST 메서드만 지원한다.
• 회원 가입, 상품 주문, 정보 수정 등에 주로 POST를 쓴다.
• 서버로 데이터가 넘어갈 때는 Content-Type: application/x-www-form-urlencoded 형식으로 변환되어 바디에 실린다.
• PUT, PATCH, DELETE 메서드를 사용할 수 없기 때문에 실무에서는 동사형 경로(컨트롤 URI)를 설계하여 한계를 극복한다.
  • 예시: POST /members/100/edit, POST /members/100/delete

 

3.4 현대적인 HTTP API(Ajax, React, App 등)를 통한 데이터 전송

• React, Vue와 같은 싱글 페이지 애플리케이션(SPA) 웹 프론트나 모바일 앱 클라이언트가 서버와 JSON으로 통신하는 현대적인 API 구조다.
• 프론트엔드가 자바스크립트 통신 엔진(Fetch API, Axios 등)을 직접 사용하기 때문에 GET, POST, PUT, PATCH, DELETE를 완벽하게 제어하여 전송할 수 있다.
• 데이터의 사실상 업계 표준 포맷은 Content-Type: application/json이다.

 

 

4. HTTP 상태 코드 완벽 정복: 1xx부터 5xx까지

상태 코드(Status Code)는 클라이언트가 서버로 보낸 HTTP 요청이 과연 어떤 결과를 맞이했는지 3자리 숫자로 일관되게 대변해주는 역할을 한다.

만약 모르는 상태 코드를 마주한다면?

수많은 상태 코드를 완벽하게 이해하고 클라이언트 코드를 작성하는 것은 어렵다. 그래서 HTTP는 클라이언트가 인식할 수 없는 임의의 상태 코드가 나타나면 백 자릿수(상위 부류)를 기준으로 기본 흐름을 처리하도록 규정하고 있다.

• 예: 클라이언트가 알지 못하는 299 코드가 오면 2xx (Successful)로 취급하여 성공 처리를 유도한다.
• 예: 451 (정부의 검열로 접근이 막힌 상태)을 받으면 4xx (Client Error)로 해석해 다시 보내지 않고 에러 처리를 유도한다.

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

요청을 서버가 정상적으로 접수하여 후속 작업을 대기 중이거나 사전 작업을 수행 중임을 알리는 임시 응답이다. 실무 웹 애플리케이션 계층에서는 거의 직접 다루거나 마주칠 일이 없는 코드군이다.

 

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

클라이언트의 요청을 서버가 성공적으로 수락하고 완결지었음을 뜻한다.

• 200 OK: 요청 성공. 가장 널리 쓰이는 표준 성공 코드다.
• 201 Created: 요청이 성공하여 서버 측에 새로운 리소스가 생성되었음을 알린다. 주로 POST를 통한 등록 성공 시 사용되며, 새로 만들어진 리소스의 접근 주소는 응답 헤더의 Location 필드에 실려서 온다.
• 202 Accepted: 요청은 접수되었으나, 아직 처리가 완료되지 않은 비동기 상태를 뜻한다. 실무에서는 대용량 엑셀 다운로드나 대규모 배치 작업(배치 프로세스가 1시간 뒤에 수행 등)처럼 즉시 응답을 주기 힘든 작업을 처리할 때 주로 쓰인다.
• 204 No Content: 요청은 아주 성공적으로 완수되었으나, 응답 메시지 바디에 담아 보낼 데이터가 전혀 없는 상태를 의미한다.
  • 실무 적용: 웹 에디터 화면의 '저장(Save)' 버튼 기능이다. 사용자가 저장 버튼을 눌렀을 때 저장 성공이라는 신호(204)만 주면 되고 화면 내용을 갱신할 필요는 없다. 200 OK로 괜히 빈 JSON을 내리는 것보다 204 코드를 내려 "너가 보고 있는 화면 상태를 그대로 유지해도 돼"라는 의도를 내포하는 데 사용한다.

 

4.3 3xx (Redirection): 추가 행동 필요

요청을 정상적으로 완료하기 위해 웹 브라우저가 응답의 Location 헤더에 담긴 새로운 경로로 자동 이동(Redirect)하도록 제어하는 코드군이다.

① 영구 리다이렉션 (301, 308)

특정 리소스의 URI가 새로운 위치로 영구히 이사했을 때 사용한다. 예전 주소(/members)로 들어오는 사용자를 검색 엔진(SEO) 점수 유실 없이 새 주소(/users)로 보내주기 위함이다.

• 301 Moved Permanently: 리다이렉션 요청이 발생하면 브라우저가 요청 메서드를 강제로 GET으로 바꾸고 본문을 소실(제거)할 수 있다.
  • 최초에 POST /old-order로 결제 요청을 보냈는데 301 리다이렉트를 타고 새 결제 주소 /new-order로 갈 때는 그냥 단순 GET /new-order로 조회가 변질되어 버려 장애를 초래할 수 있다.
• 308 Permanent Redirect: 301의 사소한 부작용을 해결하기 위해 명세에 추가된 최신 코드다. 301과 동일하지만, 리다이렉트 시 최초 요청의 메서드와 본문을 그대로 유지하도록 규율한다. POST로 왔으면 새 리다이렉트 주소로 보낼 때도 반드시 똑같이 POST와 최초 바디 데이터를 유지해야 한다.

② 일시적 리다이렉션 (302, 307, 303)

일시적인 URI 이동 상황에 사용한다. 대표적인 사례가 바로 결제 완료 후 주문 내역 화면으로 보내주는 PRG (Post-Redirect-Get) 패턴이다.

• 302 Found: 리다이렉션 시 요청 메서드가 임의로 GET으로 바뀌고 본문이 유실될 수 있다. (301과 유사한 부작용을 동반한다.)
• 307 Temporary Redirect: 302와 동일하지만, 일시적 이동 시 최초 요청의 메서드와 본문을 엄격히 유지한다. (308과 궤를 같이함)
• 303 See Other: 302와 동일하지만, 리다이렉트 시 메서드를 무조건 GET으로 변경할 것을 명시적으로 지시한다.

③ 특수 리다이렉션 (304 Not Modified)

• 서버의 자원이 마지막 요청 이후 전혀 수정되지 않았음을 알려 브라우저가 로컬에 들고 있는 캐시를 재사용하도록 권고하는 매우 고마운 코드다.
• 네트워크 바이트를 최소화해야 하므로 응답 헤더만 보내고 응답 메시지 바디를 절대로 포함하지 말아야 한다.

 

4.4 4xx (Client Error): 클라이언트 오류

요청의 구문이 잘못되었거나 잘못된 데이터를 보내는 등 실패의 원인이 전적으로 클라이언트에 있는 상황이다.

• 원인이 클라이언트에 있기 때문에 동일한 요청을 그대로 반복(Retry)해도 절대 성공할 수 없다. 클라이언트가 전송값을 올바르게 수정하는 조치(예약 필드 필수 확인, 헤더 값 검증 등)가 있어야 비로소 복구된다.
• 400 Bad Request: 클라이언트의 오타, 규격에 맞지 않는 JSON 포맷, API 스펙 불일치 등 규정에 어긋난 요청을 서버가 거절할 때 내는 대표적인 에러 코드다.
• 401 Unauthorized: 대상 리소스에 접근하기 위해 "본인이 누구인지 입증하는 단계(인증 - Authentication)"를 요구하는 응답이다.
  • 참고: 401 오류를 내릴 때는 반드시 클라이언트에게 어떻게 로그인해야 하는지 설명하는 WWW-Authenticate 헤더를 동봉하도록 규율되어 있다. 이름은 Unauthorized(인가 실패)지만 실제로는 Unauthenticated(인증되지 않음)의 의미를 지닌다.
• 403 Forbidden: 사용자가 본인이 누구인지는 입증했으나(인증 성공), 해당 리소스에 접근할 권한이 불충분할 때(인가 - Authorization) 서버가 승인을 거부하는 응답이다.
  • 실무 적용: 로그인(인증)은 완료된 일반 등급 사용자가 시스템 관리자(ADMIN) 전용 API 엔드포인트에 접속을 시도할 때 발생한다.
• 404 Not Found: 요청한 리소스가 서버 상에 존재하지 않음을 뜻한다.
  • 실무 팁: 클라이언트의 권한이 아주 불충분하여 아예 리소스가 있는 사실 자체도 숨기고 보안을 도모하고 싶을 때, 403 Forbidden 대신 의도적으로 404 Not Found를 내려 "여긴 아무것도 없어"라며 클라이언트를 따돌리는 속임수 전술로도 즐겨 쓰인다.

 

4.5 5xx (Server Error): 서버 오류

클라이언트의 요청은 아주 깔끔하고 유효하지만, 서버 내부의 버그, DB 커넥션 고갈, 혹은 시스템 먹통 현상으로 인해 정상적으로 응답을 내려주지 못하는 상태다.

• 실패의 원인이 서버에 있기 때문에, 클라이언트 입장에서는 잠시 후 동일한 요청을 그대로 재시도하면 복구 기간 내에 성공으로 전환될 수 있다.
• 500 Internal Server Error: 서버 내부의 예기치 못한 예외나 오류가 발생했을 때 범용적으로 내려주는 상태 코드다. 실무 개발 시 데이터베이스 쿼리 예외나 NullPointerException을 애플리케이션 전역 예외 처리기로 감싸지 못하면 WAS 프레임워크가 500 에러를 직접 방출한다.
• 503 Service Unavailable: 서버가 일시적인 과부하(Traffic Spike)나 예정된 정기 유지보수 작업으로 인해 잠시 요청을 완수할 수 없는 상태를 뜻한다.
  • 이때 응답 헤더에 Retry-After: 3600과 같이 얼마 후에 접속을 재시도해야 정상 가동 상태를 만날 수 있는지 구체적인 초 단위 시각을 제공할 수 있어 클라이언트 오토스케일링 재진입 제어에 도움을 준다.

 

5. 실무 백엔드 개발 시 마주하는 핵심 트랩 및 권장 설계 팁

① 수동 JSON 응답과 200 OK 남발 트랩

초보 개발자 시절 가장 흔히 저지르는 실수가 바로 백엔드에서 에러가 발생했음에도 불구하고 HTTP 응답 수준에서는 200 OK를 던지면서, 바디 데이터에 수동 에러 정보를 내려주는 형태다.

// ❌ 아주 잘못 설계된 200 OK 에러 응답 트랩
HTTP/1.1 200 OK
Content-Type: application/json

{
  "success": false,
  "code": "MEMBER_NOT_FOUND",
  "message": "회원 정보를 찾을 수 없습니다."
}

이런 설계는 브라우저와 프록시, 가용성 분석을 전담하는 가시성 수집 장비(APM, Nginx Log 등)가 요청을 정상 성공 처리로 잘못 트래킹하게 만드는 심각한 부작용을 낳는다. 이 경우 무조건 상태 코드를 404 Not Found 혹은 적절한 4xx 계열로 변경하고, 응답 공통 규격 레이어를 조합하여 내려주는 구조가 현대 웹 아키텍처의 철칙이다.

//  올바른 규격 설계 예시
HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "success": false,
  "code": "MEMBER_NOT_FOUND",
  "message": "회원 정보를 찾을 수 없습니다."
}

 

② 멱등성 보강을 위한 실무 팁 (Idempotency-Key)

POST를 사용한 비멱등 결제 시스템에서 어떻게 멱등성을 지키는지에 대한 실전 아키텍처다. 토스페이먼츠나 아임포트 등 금융 결제 솔루션들은 클라이언트가 최초 결제 요청을 보낼 때 중복 처리를 방지하기 위한 고유한 난수 값인 Idempotency-Key를 HTTP 헤더에 담아 전송하게 유도한다.

서버는 결제 프로세스를 타기 전 Idempotency-Key를 Redis 같은 고속 인메모리 저장소에 등록하고, 만약 동일한 키로 반복된 POST 요청이 수신되면 실제 트랜잭션을 실행하지 않고 이미 저장되어 있던 최초 결제 결과 값을 즉시 돌려주는 방어 처리를 수행한다.

③ 201 Created 시 Location 헤더의 포함

신규 사용자를 등록하는 POST /members 요청을 성공시킬 때는 단순히 201 코드만 덜렁 내리기보단, 응답의 Location 헤더에 /members/321과 같이 새로 생성된 자원의 식별 주소를 함께 담아서 보낸다. 이를 통해 프론트엔드 개발자는 별도의 쿼리 호출을 추가로 구성할 필요 없이 즉시 가입 완료된 프로필 상세 페이지로 화면을 전환할 수 있는 매끄러운 UX를 구현할 수 있다.

 

 

6. 결론

HTTP 메서드와 상태 코드는 시스템을 지탱하는 인프라를 한 단계 고도화시켜 여러 기능이 포함되어 있다.

• 리소스의 행동 목적에 부합하는 적확한 HTTP 메서드를 사용하고,
• 메서드의 안전·멱등 속성을 정확히 구분하여 클라이언트 자동 재시도 및 중복 주문 처리 아키텍처를 구성하며,
• 백 자릿수의 표준 의미를 왜곡하지 않고 상황별 구체적인 HTTP 상태 코드의 철학을 적용할 때,

어떤 다양한 트래픽 환경 속에서도 흔들리지 않는 견고한 백엔드 API 플랫폼을 완성할 수 있을 것이다.