요약

  • RFC 9110은 메서드 토큰을 요청 의미론의 주된 근거로 규정합니다. 메서드는 클라이언트의 목적과 기대하는 성공 결과를 나타내며, 각 대상 리소스는 독립적으로 해당 메서드가 구현되었거나 허용되는지를 판단합니다.
  • Safe는 클라이언트가 요청한 것이 무엇인지를 다루며, 모든 부작용의 부재를 뜻하지 않습니다.Idempotent는 동일한 요청이 반복될 때 의도된 서버 효과를 다루며, 동일한 응답이나 빈 로그, 확실한 복구를 뜻하지 않습니다.
  • 방어 가능한 연산은 메서드, 대상, 인증된 주체, 인가 정책, 전제조건, 첫 시도의 불확실성, 애플리케이션 수준 멱등성, 재시도 주체, 응답, 결과 상태, 별도로 관측된 부작용을 결합해야 합니다.

요청은 단호해 보이는 한 줄로 도착합니다. 메서드가 먼저 옵니다. 그다음이 대상입니다. 자격 증명, 조건, 콘텐츠가 세부를 더합니다. 게이트웨이는 메서드를 라우팅, 필터링, 캐싱, 손실 응답 재시도 여부 판단에 쓸 수 있을 만큼 이르게 확인합니다. 첫 토큰을 전체 판단으로 읽고 싶은 유혹이 듭니다.

그 유혹은 어휘와 권한을 혼동합니다. 메서드는 구현들 사이에서 공유되는 의도의 이름입니다. 그것이 발신자에게 대상에 대한 권리를 부여하지는 않습니다. 서버는 그 단어를 인식하고, 그 의미론을 구현하고, 리소스에 사용 가능함을 광고하면서도 여전히 이 주체를 거부할 수 있습니다. 주체는 수락하되 낡은 전제조건은 거부할 수 있습니다. 요청을 적용한 뒤 응답을 잃을 수 있습니다. 의도된 변경을 수행하면서 동시에 로그를 기록하거나 리비전을 생성하거나 하류 효과를 촉발할 수 있습니다.

Roy T. Fielding의 HTTP와 REST에 대한 연구는 이 사실들을 분리해 두는 규율 있는 방법을 제공합니다. 공통 인터페이스는 독립적인 구성요소들이 협력할 만큼 충분한 의도를 드러내야 합니다. 리소스 정책과 상태는 로컬에 남습니다. 인가에는 자체적인 주체와 범위가 필요합니다. 실패 복구에는 동사에서 빌린 자신감이 아니라 증거가 필요합니다.

메서드 토큰은 목적의 공개 선언이다

RFC 9110은 요청 메서드 토큰을 요청 의미론의 주된 근거로 부릅니다. 메서드는 클라이언트가 왜 요청했는지, 성공한 결과가 무엇을 의미할 것으로 기대하는지를 나타냅니다. GET은 현재 표현을 요구합니다. PUT은 선택된 대상에 표현된 상태의 생성 또는 교체를 요구합니다. DELETE는 대상 URI와 현재 기능 사이의 연관을 제거할 것을 요구합니다.

이것은 애플리케이션 동작 레이블보다 정밀합니다. 의미론이 리소스 전반에 걸쳐 표준화되어 있으므로, 구성요소는 제한된 추론을 하기 위해 모든 애플리케이션에 대한 비공개 지식이 필요하지 않습니다. 캐시는 조회와 수정을 구분할 수 있습니다. 크롤러는 안전한 메서드와 안전하지 않은 메서드를 다르게 다룰 수 있습니다. 클라이언트는 끊어진 연결 후의 반복을 추론할 수 있습니다.

그 단어는 여전히 의도입니다. 성공한 PUT이 다음 GET에서 동등한 표현이 여전히 보일 것을 보장하지 않습니다. 다른 사용자 에이전트나 동적 처리가 개입할 수 있습니다. DELETE는 저장된 모든 바이트가 파괴되거나 저장 공간이 회수될 것을 약속하지 않습니다. HTTP는 리소스 인터페이스 뒤의 구현을 의도적으로 숨깁니다.

따라서 첫 수신은 협소합니다. 클라이언트가 어떤 표준화된 의도를 표현했는가? 아직 권한이나 최종 상태에 대한 수신이 아닙니다.

균일 인터페이스는 로컬 수용 전에 끝난다

RFC 9110은 모든 리소스에 표준화된 메서드가 구현되었거나 허용되는지를 결정할 권리를 줍니다. 이 구분은 관측 가능합니다. 서버는 메서드를 인식하지 못하거나 구현하지 않을 때 501을 사용해야 합니다. 메서드를 알고 구현하지만 대상 리소스가 지원하지 않을 때는 405를 사용해야 합니다. 405 응답에는 대상이 현재 지원하는 메서드를 나열하는Allow가 포함되며, 이 집합은 동적으로 바뀔 수 있습니다.

Allow는 인가 증서가 아니라 기능 정보입니다. 컬렉션이 POST를 받아들이거나 문서가 PUT을 지원한다고 말할 수 있습니다. 익명 호출자, 서비스 계정 또는 브라우저 뒤의 직원이 필요한 역할을 가졌음을 증명하지는 않습니다. 인증은 신원을 확립하거나 검증합니다. 인가는 그 신원과 동작, 대상에 정책을 적용합니다. 메서드 지원은 다른 질문을 합니다. 이 리소스가 애초에 이 표준화된 종류의 요청을 처리할 수 있는가?

이 열들을 합치면 두 가지 반대 오류가 생깁니다. 클라이언트는 일반 메타데이터의 부재를 최종 보안 답으로 취급해 정당한 연산을 거부할 수 있습니다. 또는 광고된 메서드가 모두에게 열려 있다고 가정해 파괴적 동작을 노출할 수 있습니다. 응답 수신은 인식, 리소스 지원, 주체 인가를 세 개의 분리된 결정으로 보존해야 합니다.

이 분리는 Lu Heng의 Minimum Initial Specification을 닮았습니다. 공유 계층은 상호운용성에 필요한 의미론에 엄격하고, 이후의 선택은 리소스를 운용하는 참여자들에게 남습니다. 메서드 의미의 공개 레지스트리는 조정하지만, 모든 대상을 지배하지는 않습니다.

Safe는 책임을 배분하며 부작용을 지우지 않는다

Safe 메서드는 정의된 의미론에서 본질적으로 읽기 전용입니다. 클라이언트는 원본 서버의 상태 변경을 요청하거나 기대하지 않습니다. RFC 9110은 즉시 이 추론을 제한합니다. 서버는 접근 로그에 기록할 수 있습니다. 광고 선택은 계정에 청구할 수 있습니다. 구현은 완전히 읽기 전용이 아닌 동작을 수행할 수 있습니다. 그 효과들은 클라이언트가 요청한 것을 바꾸지 않으며, 클라이언트는 요청하지 않은 동작에 대해 책임을 지지 않습니다.

이것은 물리적 무고의 주장이 아니라 책임의 배분입니다. 자동 조회, 링크 검사, 색인 생성, 프리페치가 동작할 수 있는 이유를 설명합니다. 리소스 소유자는 안전하지 않은 동작을 Safe 메서드 밖에 두어야 합니다.page?do=delete같은 URI는 동작이 쿼리 매개변수에 숨겨져 있었다는 이유만으로 GET으로 조회될 때 삭제를 수행해서는 안 됩니다. 모든 링크를 따라가는 크롤러는 의미론적 지름길을 피해로 바꾸게 됩니다.

운영상 검증은 두 면을 가집니다. 첫째, 클라이언트의 표준화된 요청 의미론이 상태 변경을 요구했는가? 둘째, 구현이 어떤 추가 효과를 붙이기로 선택했는가? 둘을 함께 "GET의 효과"라 부르면 서버가 자신의 설계 선택을 클라이언트에 전가하게 됩니다.

Safe는 또한 인가를 뜻하지 않습니다. 기밀 표현은 Safe 메서드로 조회되면서도 여전히 권한을 요구할 수 있습니다. 읽기 전용 접근은 공개하고, 청구하고, 속도를 제한하고, 존재를 드러낼 수 있습니다. 메서드 속성은 자동화에 요청된 피해의 경계를 알려줄 뿐이며, 누가 그 경계를 넘을 수 있는지는 여전히 인가 시스템이 결정합니다.

Idempotent는 의도된 효과를 보존하며 동일한 세계를 보존하지 않는다

멱등 메서드는 동일한 요청이 여러 번 적용될 때 한 번 적용될 때와 같은 의도된 서버 효과를 가집니다. PUT, DELETE 및 Safe 메서드는 RFC 9110 아래에서 이 속성을 갖습니다. 정의는 다시 요청된 의도에 머뭅니다. 서버는 모든 요청을 별도로 기록하고, 여러 리비전 기록을 보존하고, 시도별 다른 부작용을 만들 수 있습니다.

응답도 다를 수 있습니다. 첫 DELETE는 URI 연관을 제거하고 성공을 반환할 수 있습니다. 반복된 DELETE는 리소스가 이미 없다고 보고할 수 있습니다. 의도된 상태는 여전히 같습니다. 반복된 PUT은 동일한 대상 상태에 도달하면서 날짜, 검증자 또는 결과의 표현을 새로 받을 수 있습니다.

애플리케이션 설계는 유용한 추론을 좁히거나 무력화할 수 있습니다. 대상 상태를 교체하는 대신 잔액을 증가시키는 명목상 PUT 엔드포인트는 보이는 의도를 위반합니다. 시도마다 새로운 되돌릴 수 없는 외부 지시를 보내는 DELETE는 로컬 URI 상태를 보존하면서 하류 결과를 곱셈으로 늘릴 수 있습니다. 메서드 수준 멱등성은 보편적 트랜잭션 보장이 아닙니다.

수신에는 두 계층이 모두 필요합니다. 표준화된 속성과, 의도된 효과가 실제로 중복 제거되거나 수렴한다는 애플리케이션의 증거입니다. 하류 시스템이 관여한다면 각 효과는 자체 멱등성 키, 커밋 상태 또는 보상 경로를 필요로 합니다.

재시도는 첫 시도에 대한 불확실성에서 시작한다

멱등성은 클라이언트가 응답을 읽기 전에 연결이 실패할 때 가장 중요합니다. 서버는 요청을 적용했을 수도, 아무것도 받지 못했을 수도, 커밋 후에 응답을 잃었을 수도 있습니다. 멱등 요청의 재시도는 첫 시도가 성공했더라도 반복이 같은 의도된 효과에 도달해야 하므로 합리적입니다.

합리적이란 무제한이 아닙니다. RFC 9110은 클라이언트가 해당 리소스에 대해 멱등임을 알거나 원래 요청이 적용된 적 없음을 판단할 수 없다면 비멱등 메서드를 자동으로 재시도해서는 안 된다고 규정합니다. 프록시는 비멱등 요청을 자동으로 재시도해서는 안 됩니다. 클라이언트는 실패한 자동 재시도를 다시 자동으로 재시도해서는 안 됩니다.

메서드는 복구 결정의 한 입력입니다. 클라이언트는 대상, 연결 실패 지점, 애플리케이션 계약, 요청 콘텐츠, 전제조건, 중복 제거 식별자도 필요로 합니다. "PUT은 멱등하다"는 맹목 루프를 정당화할 수 없습니다. "POST는 비멱등하다"는 애플리케이션이 안정적인 연산 키와 상태 엔드포인트를 가진다면 리소스별 재시도를 금지하지 않습니다.

여기서 Running-Code Primacy가 유용합니다. 의미 있는 증거는 메서드에 붙은 제도적 레이블이 아니라 독립적인 참여자가 검증할 수 있는 동작입니다. 중복 시도가 수렴하는지, 커밋된 연산을 조회할 수 있는지, 부작용이 경계 내에 남는지 여부입니다.

전제조건은 버전을 보호하며 주체를 보호하지 않는다

조건부 헤더는 메서드와 모순되지 않으면서 메서드를 정밀화합니다.If-Match는 상태 변경 요청이 적용되기 전에 현재 선택된 표현이 알려진 엔터티 태그를 가져야 함을 요구할 수 있습니다. 조건이 실패하면 서버는 요청된 메서드를 수행하지 않고 보통 412를 반환합니다. 이는 편집자가 다른 사람이 바꾼 버전을 덮어쓰는 것을 막습니다.

검증자는 편집자가 누구인지, 그 편집자가 쓰기가 허용되는지를 확립하지 않습니다. 유출된 ETag는 베어러 자격 증명이 아닙니다. 유효한 자격 증명이 낡은 ETag를 현재로 만들지는 않습니다. 서버는 인가와 리소스 전제조건을 모두 평가하며 각 거부의 이유를 보존해야 합니다.

불확실한 재시도에서 전제조건은 결과를 드러낼 수도 있습니다. 요청된 변경이 이미 적용된 것으로 보이면 RFC 9110은 한정된 상황에서 성공 응답을 허용하면서 유사한 비조율 작성자에 대해 경고합니다. 비원자적 증가로 쓰이는 리소스는 알려진 문서 상태의 교체보다 엄격한 처리를 필요로 합니다.

정결한 사슬은 주체, 권한, 리소스 버전, 요청된 의도, 애플리케이션, 결과입니다. 시스템이 기록하지 않는 한 단일 녹색 응답은 사후에 그 사슬을 재구성할 수 없습니다.

QUERY는 작은 어휘도 여전히 진화할 수 있음을 보여준다

2026년 6월, RFC 10008이 QUERY를 정의했습니다. 저자는 Julian Reschke, James Snell, Mike Bishop이며 Fielding이 아닙니다. QUERY는 POST처럼 요청 콘텐츠를 실지만 안전하고 멱등한 질의임을 선언합니다. IANA는 현재 Safe와 Idempotent를 모두 yes로 기록하고 있습니다.

문제는 가시성입니다. 애플리케이션은 URI가 너무 길거나 질의 데이터가 로그와 북마크에 노출되기 때문에 복잡한 읽기 전용 질의를 종종 POST 본문으로 보냅니다. 리소스별 지식이 없으면 일반 구성요소는 POST를 보고 그 연산이 안전하거나 반복 가능하다는 것을 알 수 없습니다. QUERY는 대상이 질의 콘텐츠를 정의하고 지원 여부를 결정하도록 남겨 둔 채 그 의도를 공개합니다.

등록이 메서드를 배포하지는 않습니다. 서버가 구현하게 하거나, 게이트웨이가 전달하게 하거나, 주체에게 사용 자격을 주지 않습니다. 채택하는 구성요소들에게 공유 의미를 제공할 뿐입니다. 공통의 새 단어가 비공개 추론을 줄이고 로컬 수용을 가시적으로 남기는, 자발적 기술 조정의 가장 유용한 모습입니다.

IANA 레지스트리는 어휘 원장으로 읽어야 합니다. Safe와 Idempotent 열은 사양에 뒷받침된 간결한 동작 선언입니다. 접근 통제 목록이 아닙니다.

Fielding의 기여는 인터페이스 경계이며 소유권이 아니다

2026년 8월 31일에 검토한 IETF Datatracker는 Roy T. Fielding을 Adobe의 Senior Principal Scientist, The Apache Software Foundation 공동 창립자, REST 아키텍처 스타일의 저자, HTTP·URI·URI Templates 기여자로 기록합니다. 18개의 RFC와 HTTP Directorate 검토자 역할을 나열합니다. UC Irvine은 그의 학위와 웹, REST, Apache 기여를 기록합니다.

그의 박사 논문은 균일 인터페이스를 REST 제약으로 설명합니다. 표준화는 네트워크 구성요소 전반의 가시성과 재사용을 개선하지만 일부 애플리케이션별 효율을 거래합니다. 메서드 어휘는 그 거래의 직접적 예입니다. 작은 공통 의미론 집합은 중개자가 애플리케이션 내부를 보지 않고도 의도를 이해하게 합니다.

귀속은 경계 내에 남아야 합니다. RFC 9110에는 세 편집자가 있습니다. Fielding, Mark Nottingham, Julian Reschke입니다. HTTP는 집단적이고 개정된 작업입니다. 현재 구현들은 각자의 결정을 내립니다. RFC 10008은 명명된 저자들에게 속합니다. Fielding의 서명은 기여를 추적 가능하게 만들 뿐, 프로토콜의 소유권이나 모든 대상에 대한 권한을 주지 않습니다.

그 경계가 본 글의 논지를 강화합니다. 표준은 권한의 근원이 되지 않으면서 의도를 조정할 수 있습니다. 편집자는 공용 언어의 주권자가 되지 않으면서 그 언어를 형성할 수 있습니다.

동사 지름길을 연산 수신으로 대체하라

민감하거나 자동 재시도되는 모든 연산에 대해 먼저 메서드와 대상을 기록하십시오. 그다음 인증된 주체, 자격 증명 범위, 리소스의 지원 메서드 결정, 인가 정책과 버전, 관련 ETag 또는 다른 전제조건, 요청 콘텐츠 해시와 의도된 효과를 기록합니다.

실패가 발생하면 마지막 확인된 전송 지점, 첫 시도가 적용되었을 가능성, 애플리케이션 멱등성 키 또는 수렴 증명, 재시도를 개시한 주체, 트리거, 시도 횟수와 백오프를 추가합니다. 응답, 결과 리소스 상태, 하류 효과, 보상, 되돌릴 수 없는 결과로 마무리합니다.

이 수신은 짧은 토큰 하나를 제자리에 둡니다. 메서드는 독립적인 구성요소에 클라이언트가 무엇을 묻려는지 알려줍니다. 리소스는 이해하는지를 말합니다. 인가는 이 주체가 여기서 묻을 수 있는지를 말합니다. 전제조건은 상태가 여전히 요청이 가정한 것인지를 말합니다. 재시도 증거는 또 하나의 시도가 정당한지를 말합니다. 관측된 상태는 실제 무엇이 일어났는지 말합니다.

균일 인터페이스는 그 질문들이 하나의 질문이 되지 않고 결합될 수 있기 때문에 작동합니다. 메서드는 의도의 이름입니다. 권한을 부여하지 않습니다.

출처