두 번째 발걸음HTTP 메시지에서 동작과 결과를 읽는다

HTTP는 요청과 응답으로 자원을 다루는 애플리케이션 프로토콜입니다. 주소의 경로는 어떤 자원을 요청하는지, 메서드는 어떤 의미의 동작인지 나타냅니다. 헤더에는 표현 형식, 인증 정보, 캐시 조건 같은 부가 정보가 들어가고 본문에는 실제 데이터가 담길 수 있습니다. 다음은 사람이 구조를 읽기 쉬운 HTTP/1.1 형식입니다. HTTP/2·3은 전송 프레임이 달라도 메서드와 상태 코드 등 핵심 의미를 이어 사용합니다.

GET /catalog/42 HTTP/1.1
Host: shop.example
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 23
Cache-Control: no-store

{"id":42,"price":12000}

GET은 자원의 표현을 가져오는 의미이고, HEAD는 본문 없이 그에 대응하는 메타데이터를 확인합니다. POST는 요청한 자원에 데이터를 처리하도록 제출하며 주문 생성처럼 새 상태를 만들 수 있습니다. PUT은 지정 자원의 상태를 주어진 표현으로 대체하는 의미이고 DELETE는 대상 자원과의 연결을 제거하도록 요청합니다. 서버는 필요한 메서드만 구현하고 권한을 확인해야 합니다. 낯선 메서드를 전부 허용하거나, 메서드 이름만 바꾸면 같은 동작을 통과시키는 설계는 검토 대상입니다.

안전한 메서드라는 표준 용어는 클라이언트가 서버의 상태 변경을 요청하지 않는 의미를 말합니다. GET을 호출할 때 로그가 전혀 남지 않는다는 뜻은 아닙니다. 멱등성은 같은 요청을 여러 번 적용했을 때 의도된 효과가 한 번 적용한 것과 같은 성질입니다. PUT과 DELETE가 멱등적 의미를 갖더라도 재시도 때 응답 코드가 언제나 같을 필요는 없습니다. 첫 DELETE가 성공하고 두 번째는 이미 없는 자원이라고 답할 수 있습니다. 결제처럼 중복 처리의 비용이 큰 업무에서는 이 의미를 서버의 상태 관리로 실제 보장해야 합니다.

상태 코드는 처리 결과의 종류를 보여 줍니다. 2xx는 성공, 3xx는 추가 이동이나 캐시 관련 처리, 4xx는 요청과 관련된 문제, 5xx는 서버가 처리하지 못한 문제를 나타냅니다. 401은 유효한 인증 자격 증명이 부족한 상황에, 403은 요청을 이해했지만 허용하지 않는 상황에 사용합니다. 보안 정책에 따라 자원의 존재를 숨기려고 404로 응답할 수 있으므로 외부 코드 하나로 내부 원인을 단정하지 않습니다. 사용자에게 필요한 메시지와 운영자가 볼 상세 원인 기록을 분리합니다.

HTTPS는 HTTP를 TLS로 보호한 연결입니다. HSTS는 브라우저에 해당 호스트를 일정 기간 HTTPS로만 접속하도록 알려 평문으로의 전환 위험을 줄입니다. HSTS를 도입하기 전에 대상 호스트와 필요하면 하위 도메인의 HTTPS 준비 상태를 확인합니다. 헤더를 받기 전의 첫 방문 문제와 미리 등록된 정책의 차이도 있습니다. 암호화 설정과 브라우저 정책이 올바르더라도 본문의 권한 검사나 입력 처리는 애플리케이션의 책임으로 남습니다.

참고　[167] · [169] · [170]