PATCH 콘텐츠 유형에 대한 질문이 있습니다. 내 앱은 퍼블릭 클라우드에서 실행되는 스프링 부트 애플리케이션입니다. 내 우려는 Patch 동사가 contentType을 application / json-patch + json 대신 application / json으로 가질 수 있는지 여부입니다.
평범한 json을 사용하는 경우 어떤 단점이 있습니까?
평범한 json을 사용하는 경우 어떤 단점이 있습니까?
예
패치 동사는 contentType이 application / json-patch + json 대신 application / json이 될 수 있습니까?
HTTP 패치는 요청에 다음을 포함하는 패치 문서를 포함해야한다고 말합니다.
현재 원본 서버에있는 자원이 새 버전을 생성하기 위해 수정되어야하는 방법을 설명하는 일련의 지침.
PATCH /foo HTTP/1.1
Content-Type: text/plain
Replace "ghoti" with "fish"
완벽하게 잘 구성된 패치 요청이며 /foo리소스에 대한 편집을 제안 합니다.
하지만이 예제에는 모호한 부분이 있습니다.이 패치는 ghoti의 한 인스턴스를 대체한다고 말합니까? 아니면 ghoti의 모든 인스턴스? 클라이언트와 서버가 동일한 방식으로이 메시지를 이해하도록하려면 해당 지점에 대해 일종의 동의가 필요합니다.
REST의 요점은 이러한 계약이 쉽게 표준화 가능한 형식을 가져야한다는 것 입니다.
서버에서 지원하는 패치 문서에 대한 계약은 자체적으로 Accept-Patch 헤더 (HTTP 패치 사양에 정의 됨)에 의해 설명됩니다. 헤더 값은 미디어 유형입니다. 그런 다음 해당 미디어 유형의 정의를 찾아 내 변경 사항을 설명하는 방법을 알아낼 수 있습니다.
또한 광고 된 미디어 유형이 이미 알고있는 미디어 유형 인 경우 이전 솔루션을 다시 사용할 수 있습니다. application / json-patch + json 표준 또는 application / merge-patch + json 표준을 갖는 요점은 우리 모두가 이러한 문서를 동일한 방식으로 이해한다는 것입니다. 그래서 우리는 interop을 얻습니다-모든 application / json-patch + json 가능 클라이언트는 모든 application / json-patch + json 가능 서버와 성공적으로 통신 할 수 있습니다.
application / json은 이러한 방식으로 작동하지 않습니다. JSON 사양에는 PATCH 컨텍스트에서 JSON 문서를 해석하는 방법에 대한 일반적인 이해를 생성하는 것이 없기 때문입니다. 대신 올바른 작업을 수행하려면 다른 "대역 외"정보가 필요합니다.
예를 들어 서버와 클라이언트 구현을 모두 제어하는 경우와 같이 컨텍스트에서 interop이 중요하지 않은 경우 일부 공통 표준에 맞추는 것도 그다지 중요하지 않습니다. 웹 페이지는 백엔드와 통신하는 자바 스크립트를 호스팅하며 여기에서 변경 사항을 조정하기 쉬운 한 여기에서 사용하는 메시지 스키마가 다른 곳에서 사용되는 것과 일치하는 것은 특히 중요하지 않습니다.
그러나 대신 "웹 규모"채택을 위해 노력하고 있다면 이미 게시 된 범용 작업을 활용하는 방법을 설계에서 고려해야합니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다