나는 각 변경 사항을 감사하고 각 변경 사항에 대해 지정된 이유가 필요한 시스템에서 작업합니다. 좋은 REST 디자인을 유지하기 위해 HTTP 동사를 올바르게 사용하려고합니다.PUT 요청에서 "변경 이유"를 처리하는 방법?
이 특별한 경우와 관련하여이 상황을 처리하는 가장 좋은 방법은 확실치 않습니다. 우리는 간단한 개체가 있다고 가정하자 : 지금은 '사용자 1'에서 'USR1'에서 이름을 업데이트 할 경우
URL: /users/100
JSON: { username: 'usr1', firstName: 'John', lastName: 'Smith' }
을, 우리의 시스템은 내가 변화에 대한 이유를 지정해야합니다.
변경 이유가 없으면 JSON을 URL로 쉽게 푸싱 할 수 있습니다.
내 질문은 서버에 변경 이유를 보내는 가장 좋은 방법입니다. 여기까지 와야 할 옵션이 있습니다 :
- 엔티티에 changeReason 속성을 추가하십시오.
- 쿼리 매개 변수로 changeReason을 추가하십시오.
- changeReason 헤더를 추가하십시오.
이 옵션 중 어느 것도 나에게 맞는 것 같지 않습니다. 전에 누구도이 문제를 다루었습니까?
응답 해 주셔서 감사합니다. 나는 내 선택권이 옳지 않다는 것을 알고 있었고 나는이 방법을 좋아한다. 패치를 작성하는 방법에 대한 귀하의 의견은 무엇입니까? 이 기사 (http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/)는보다 일반적인 방식으로 설명합니다. PATCH 요청의 구조가 중요합니까? –
필자는 그 기사에서 '패치'가 종종 잘못 사용되는 것에 동의합니다.스펙이 전용'mime-type '을 요구하기 때문에'PATCH'의 구조가 중요합니다. (물론 신경 쓰지 않는다면) 제안 된'RFC 6902' 형식은 내가 볼 수있는 한 추가 정보를 허용하지 않습니다. 또한 json-document-change는 제 취향에 맞는 것입니다. 다소 일반적인 방식으로 변경 사항을 설명하는 한 자신 만의 표현을 작성할 수 있습니다. –
그래서이 길을 약간 지나친 후, 원래의 질문에서 빠진 것들 중 하나는 개개의 변화가 변화의 이유를 필요로한다는 것입니다. [{op : 'replace', 경로 : 'email', 값 : '[email protected]', changeReason : '주소 입력 오류'}]를 사용하는 모델에 올바른 방법을 사용하는 것처럼 보입니까? ? –