RESTful 서비스는 변경 가능한 리소스에 읽기 전용 속성을 어떻게 표시해야합니까?

Question

변경할 수있는 속성 집합 및 변경 불가능한 서비스 집합 (예 : status은 서비스에서 생성되며 클라이언트가 변경할 수없는 집합)이있는이 서비스의 리소스를 디자인하기 위해 노력하고 있습니다.

GET 리소스 요청에 대한 응답에 이것을 포함해야하지만 누군가가 PUT 요청 리소스를 보내는 경우 어떻게해야할지 잘 모릅니다.

호출자가 어떤 속성이 불변인지 알도록 강요하지만 자동으로 업데이트를 버리는 것은 잘못된 것으로 느낍니다. PUT 요청에 대한 업데이트 된 리소스로 응답하면 문제가 해결 될 수 있지만 속성이 승인되었는지 여부를 확인하기 위해 발신자가 요청과 서비스의 응답을 비교할 필요가 없으므로 불완전합니다.

앞으로 나아갈 생각이 있으십니까?

P. How should I update a REST resource?을 보았지만이 질문과 다른 점이 많고 지나치게 수다스러운 API 디자인을 권장합니다.

Answer 1

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.10의 가이드 라인을 따르는 것이 좋습니다. HTTP 409의 정의에는 다음이 포함됩니다.

1) 자원의 현재 상태와 충돌하여 요청을 완료 할 수 없습니다.

2) 응답 본문에는 사용자가 충돌 소스를 인식 할 수있는 충분한 정보가 포함되어야합니다 (SHOULD).

따라서 변경 불가능한 속성의 변경 사항은 리소스 상태에 문제가 있으므로 HTTP 409가 적용되는 것으로 보입니다.

고객에게 문제를 전달하는 방법에 대한 지침은 응답 본문에 세부 정보를 포함하는 것 같습니다.

또한 GET에서 표현 자체에서 속성의 변경 가능성을 전달할 수 있습니다. 예를 들어.

Answer 2

API의 응답을 설계하여 읽기 전용 속성이 실제로 변경 가능한 속성과 분리되도록 할 수 있습니다. 예를 들면 다음과 같습니다.

이 작업을 수행하는 API는 모두 작성 및 사용했으며 제대로 작동합니다.

Answer 3

JSON-Patch 문서와 함께 HTTP PATCH를 사용하면 수정하려는 속성을 정확하게 정확히 집어 넣을 수 있습니다. http://tools.ietf.org/html/rfc6902을 참조하십시오.

하지만 불변 및 변경 가능 요소를 모두 PUT하는 데는 아무런 문제가 없습니다. 서버는 변경하기를 원하지 않는 것을 자유롭게 무시할 수 있습니다. 이 주제에 대한 심층적 인 토론을 여기에 썼습니다 : http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html