Internet Engineering Task Force (IETF) P. Bryan, Ed.
Request for Comments: 6902 Salesforce.com
Category: Standards Track M. Nottingham, Ed.
ISSN: 2070-1721 Akamai
April 2013
JavaScript Object Notation (JSON) Patch
초록
JSON Patch는 JavaScript Object Notation(JSON) 문서에 적용할
일련의 작업을 표현하기 위한 JSON 문서 구조를 정의한다. 이는
HTTP PATCH 메서드와 함께 사용하기에 적합하다.
"application/json-patch+json" 미디어 타입은 이러한 패치 문서를
식별하는 데 사용된다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서이다.
이 문서는 Internet Engineering Task Force(IETF)의 산출물이다.
이는 IETF 커뮤니티의 합의를 나타낸다. 공개 검토를 거쳤으며
Internet Engineering Steering Group(IESG)의 승인을 받아
출판되었다. 인터넷 표준에 관한 추가 정보는 RFC 5741의
섹션 2에서 확인할 수 있다.
이 문서의 현재 상태, 정오표, 그리고 피드백 제공 방법에 관한
정보는 http://www.rfc-editor.org/info/rfc6902에서 확인할 수 있다.
저작권 고지
Copyright (c) 2013 IETF Trust 및 문서 저자로 식별된 사람들.
모든 권리 보유.
이 문서는 출판일 현재 유효한 BCP 78 및 IETF Trust의
IETF 문서에 관한 법적 조항
(http://trustee.ietf.org/license-info)의 적용을 받는다.
이 문서에 관한 권리와 제한 사항이 설명되어 있으므로 이들 문서를
주의 깊게 검토하기 바란다. 이 문서에서 추출된 코드 구성요소는
Trust Legal Provisions의 Section 4.e에 설명된 Simplified BSD
License 텍스트를 포함해야 하며, Simplified BSD License에
설명된 바와 같이 보증 없이 제공된다.
Bryan & Nottingham Standards Track [Page 1]
RFC 6902 JSON Patch April 2013
목차
1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 규약 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. 문서 구조 . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 작업 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. add . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. remove . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. replace . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. move . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.5. copy . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. test . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. 오류 처리 . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA 고려사항 . . . . . . . . . . . . . . . . . . . . . . 9
7. 보안 고려사항 . . . . . . . . . . . . . . . . . . . . . . 10
8. 감사의 말 . . . . . . . . . . . . . . . . . . . . . . . . 10
9. 참고문헌 . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. 규범적 참고문헌 . . . . . . . . . . . . . . . . . . . 10
9.2. 참고용 참고문헌 . . . . . . . . . . . . . . . . . . . 10
부록 A. 예제 . . . . . . . . . . . . . . . . . . . . . . . . 12
A.1. 객체 멤버 추가 . . . . . . . . . . . . . . . . . . . 12
A.2. 배열 요소 추가 . . . . . . . . . . . . . . . . . . . 12
A.3. 객체 멤버 제거 . . . . . . . . . . . . . . . . . . . 12
A.4. 배열 요소 제거 . . . . . . . . . . . . . . . . . . . 13
A.5. 값 교체 . . . . . . . . . . . . . . . . . . . . . . . 13
A.6. 값 이동 . . . . . . . . . . . . . . . . . . . . . . . 14
A.7. 배열 요소 이동 . . . . . . . . . . . . . . . . . . . 14
A.8. 값 테스트: 성공 . . . . . . . . . . . . . . . . . . . 15
A.9. 값 테스트: 오류 . . . . . . . . . . . . . . . . . . . 15
A.10. 중첩 멤버 객체 추가 . . . . . . . . . . . . . . . . 15
A.11. 인식되지 않는 요소 무시 . . . . . . . . . . . . . . . 16
A.12. 존재하지 않는 대상에 추가 . . . . . . . . . . . . . . 16
A.13. 유효하지 않은 JSON Patch 문서 . . . . . . . . . . . 17
A.14. ~ 이스케이프 순서 . . . . . . . . . . . . . . . . . . 17
A.15. 문자열과 숫자 비교 . . . . . . . . . . . . . . . . . 17
A.16. 배열 값 추가 . . . . . . . . . . . . . . . . . . . . 18
Bryan & Nottingham Standards Track [Page 2]
RFC 6902 JSON Patch April 2013
1. 소개
JavaScript Object Notation(JSON) [RFC4627]는 구조화된 데이터의
교환 및 저장을 위한 일반적인 형식이다. HTTP PATCH [RFC5789]는
Hypertext Transfer Protocol(HTTP) [RFC2616]을 확장하여
리소스에 대한 부분 수정을 수행하는 메서드를 제공한다.
JSON Patch는 대상 JSON 문서에 적용할 일련의 작업을 표현하기 위한
형식("application/json-patch+json" 미디어 타입으로 식별됨)이며,
HTTP PATCH 메서드와 함께 사용하기에 적합하다.
이 형식은 JSON 문서 또는 유사한 제약을 가진 데이터 구조
(즉, JSON 문법을 사용하여 객체나 배열로 직렬화될 수 있는 구조)에
부분 업데이트를 수행해야 하는 다른 경우에도 잠재적으로 유용하다.
2. 규약
이 문서의 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
"OPTIONAL"은 RFC 2119 [RFC2119]에 설명된 대로 해석한다.
3. 문서 구조
JSON Patch 문서는 객체의 배열을 나타내는 JSON [RFC4627] 문서이다.
각 객체는 대상 JSON 문서에 적용될 단일 작업을 나타낸다.
다음은 HTTP PATCH 요청으로 전송되는 JSON Patch 문서의 예이다.
PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: "abc123"
[
{ "op": "test", "path": "/a/b/c", "value": "foo" },
{ "op": "remove", "path": "/a/b/c" },
{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]
Bryan & Nottingham Standards Track [Page 3]
RFC 6902 JSON Patch April 2013
JSON Patch 문서의 평가는 대상 JSON 문서에 대해 시작된다.
작업은 배열에 나타난 순서대로 순차적으로 적용된다. 시퀀스의 각
작업은 대상 문서에 적용되며, 그 결과 문서가 다음 작업의 대상이
된다. 평가는 모든 작업이 성공적으로 적용되거나 오류 조건이
발생할 때까지 계속된다.
4. 작업
작업 객체는 수행할 작업을 나타내는 값을 가진 "op" 멤버를 정확히
하나 가져야 한다(MUST). 그 값은 "add", "remove", "replace",
"move", "copy" 또는 "test" 중 하나여야 하며(MUST), 다른 값은
오류이다. 각 객체의 의미는 아래에 정의된다.
또한 작업 객체는 "path" 멤버를 정확히 하나 가져야 한다(MUST).
이 멤버의 값은 작업이 수행될 대상 문서 내 위치("대상 위치")를
참조하는 JSON-Pointer 값 [RFC6901]을 포함하는 문자열이다.
다른 작업 객체 멤버의 의미는 작업별로 정의된다(아래 하위 섹션
참조). 해당 작업에 대해 명시적으로 정의되지 않은 멤버는 반드시
무시되어야 한다(MUST) (즉, 정의되지 않은 멤버가 객체에 나타나지
않은 것처럼 작업이 완료된다).
JSON 객체에서 멤버의 순서는 중요하지 않다. 따라서 다음 작업
객체들은 동등하다.
{ "op": "add", "path": "/a/b/c", "value": "foo" }
{ "path": "/a/b/c", "op": "add", "value": "foo" }
{ "value": "foo", "path": "/a/b/c", "op": "add" }
작업은 JSON 문서로 표현되는 데이터 구조에 적용된다. 즉,
(see [RFC4627], Section 2.5)에 따른 이스케이프 해제가
수행된 후 적용된다.
4.1. add
"add" 작업은 대상 위치가 참조하는 항목에 따라 다음 기능 중
하나를 수행한다.
o 대상 위치가 배열 인덱스를 지정하는 경우, 새 값이 지정된
인덱스의 배열에 삽입된다.
o 대상 위치가 아직 존재하지 않는 객체 멤버를 지정하는 경우,
새 멤버가 객체에 추가된다.
Bryan & Nottingham Standards Track [Page 4]
RFC 6902 JSON Patch April 2013
o 대상 위치가 이미 존재하는 객체 멤버를 지정하는 경우,
그 멤버의 값이 교체된다.
작업 객체는 추가할 값을 지정하는 내용을 가진 "value" 멤버를
포함해야 한다(MUST).
예를 들면 다음과 같다.
{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }
작업이 적용될 때 대상 위치는 다음 중 하나를 참조해야 한다(MUST).
o 대상 문서의 루트 - 이 경우 지정된 값이 대상 문서의 전체
내용이 된다.
o 기존 객체에 추가할 멤버 - 이 경우 제공된 값이 표시된 위치의
해당 객체에 추가된다. 멤버가 이미 존재하면 지정된 값으로
교체된다.
o 기존 배열에 추가할 요소 - 이 경우 제공된 값이 표시된 위치의
배열에 추가된다. 지정된 인덱스 이상의 모든 요소는 오른쪽으로
한 위치씩 이동한다. 지정된 인덱스는 배열의 요소 수보다 커서는
안 된다(MUST NOT). "-" 문자를 배열의 끝을 인덱싱하는 데
사용하면([RFC6901] 참조), 값이 배열에 추가되는 효과가 있다.
이 작업은 기존 객체와 배열에 추가하도록 설계되었으므로,
대상 위치가 존재하지 않는 경우가 많다. 따라서 포인터의 오류 처리
알고리즘이 호출되더라도, 이 명세는 "add" 포인터에 대한 오류
처리 동작을 그 오류를 무시하고 지정된 대로 값을 추가하도록
정의한다.
그러나 객체 자체 또는 그것을 포함하는 배열은 존재해야 하며,
그렇지 않은 경우는 여전히 오류이다. 예를 들어, 다음 문서에서
시작하여 대상 위치 "/a/b"에 대한 "add"는
{ "a": { "foo": 1 } }
오류가 아니다. "a"가 존재하고, "b"가 그 값에 추가될 것이기
때문이다. 다음 문서에서는 오류이다.
{ "q": { "bar": 2 } }
"a"가 존재하지 않기 때문이다.
Bryan & Nottingham Standards Track [Page 5]
RFC 6902 JSON Patch April 2013
4.2. remove
"remove" 작업은 대상 위치의 값을 제거한다.
작업이 성공하려면 대상 위치가 존재해야 한다(MUST).
예를 들면 다음과 같다.
{ "op": "remove", "path": "/a/b/c" }
배열에서 요소를 제거하는 경우, 지정된 인덱스 위의 모든 요소는
왼쪽으로 한 위치씩 이동한다.
4.3. replace
"replace" 작업은 대상 위치의 값을 새 값으로 교체한다. 작업
객체는 교체 값을 지정하는 내용을 가진 "value" 멤버를 포함해야
한다(MUST).
작업이 성공하려면 대상 위치가 존재해야 한다(MUST).
예를 들면 다음과 같다.
{ "op": "replace", "path": "/a/b/c", "value": 42 }
이 작업은 기능적으로, 값에 대한 "remove" 작업 직후 같은 위치에
교체 값을 사용하여 수행하는 "add" 작업과 동일하다.
4.4. move
"move" 작업은 지정된 위치의 값을 제거하고 대상 위치에 추가한다.
작업 객체는 "from" 멤버를 포함해야 하며(MUST), 이는 대상
문서에서 이동할 값의 위치를 참조하는 JSON Pointer 값을 포함하는
문자열이다.
작업이 성공하려면 "from" 위치가 존재해야 한다(MUST).
예를 들면 다음과 같다.
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" }
이 작업은 기능적으로, "from" 위치에 대한 "remove" 작업 직후
방금 제거한 값을 사용하여 대상 위치에 수행하는 "add" 작업과
동일하다.
Bryan & Nottingham Standards Track [Page 6]
RFC 6902 JSON Patch April 2013
"from" 위치는 "path" 위치의 proper prefix여서는 안 된다(MUST NOT).
즉, 어떤 위치도 그 하위 항목 중 하나로 이동될 수 없다.
4.5. copy
"copy" 작업은 지정된 위치의 값을 대상 위치로 복사한다.
작업 객체는 "from" 멤버를 포함해야 하며(MUST), 이는 대상
문서에서 복사할 값의 위치를 참조하는 JSON Pointer 값을 포함하는
문자열이다.
작업이 성공하려면 "from" 위치가 존재해야 한다(MUST).
예를 들면 다음과 같다.
{ "op": "copy", "from": "/a/b/c", "path": "/a/b/e" }
이 작업은 기능적으로, "from" 멤버에 지정된 값을 사용하여 대상
위치에 수행하는 "add" 작업과 동일하다.
4.6. test
"test" 작업은 대상 위치의 값이 지정된 값과 같은지 테스트한다.
작업 객체는 대상 위치의 값과 비교할 값을 전달하는 "value" 멤버를
포함해야 한다(MUST).
작업이 성공한 것으로 간주되려면 대상 위치가 "value" 값과 같아야
한다(MUST).
여기서 "equal"은 대상 위치의 값과 "value"로 전달된 값이 같은
JSON 타입이며, 해당 타입에 대한 다음 규칙에 따라 같다고
간주됨을 의미한다.
o 문자열: 동일한 수의 Unicode 문자를 포함하고 코드 포인트가
바이트 단위로 같으면 같다고 간주된다.
o 숫자: 수치적으로 값이 같으면 같다고 간주된다.
o 배열: 동일한 수의 값을 포함하고, 각 값이 이 타입별 규칙
목록을 사용하여 다른 배열의 해당 위치의 값과 같다고 간주될 수
있으면 같다고 간주된다.
Bryan & Nottingham Standards Track [Page 7]
RFC 6902 JSON Patch April 2013
o 객체: 동일한 수의 멤버를 포함하고, 각 멤버가 키(문자열)를
비교하고 값(이 타입별 규칙 목록 사용)을 비교하여 다른 객체의
멤버와 같다고 간주될 수 있으면 같다고 간주된다.
o 리터럴(false, true, null): 동일하면 같다고 간주된다.
수행되는 비교는 논리적 비교임에 유의한다. 예를 들어, 배열의
멤버 값 사이의 공백은 중요하지 않다.
또한 객체 멤버의 직렬화 순서는 중요하지 않다.
예를 들면 다음과 같다.
{ "op": "test", "path": "/a/b/c", "value": "foo" }
5. 오류 처리
JSON Patch 문서가 규범적 요구사항을 위반하거나 작업이 성공하지
못한 경우, JSON Patch 문서의 평가는 종료되어야 하며(SHOULD),
전체 패치 문서의 적용은 성공한 것으로 간주되어서는 안 된다
(SHALL NOT).
JSON Patch가 HTTP PATCH 메서드와 함께 사용될 때 오류를 처리하는
데 관한 고려사항, 다양한 조건을 나타내기 위해 사용할 권장 상태
코드 등을 보려면 [RFC5789], Section 2.2를 참조한다.
HTTP PATCH 메서드는 [RFC5789]에 따라 원자적이라는 점에 유의한다.
따라서 다음 패치는 ("test" 작업이 오류를 발생시키기 때문에)
문서에 아무 변경도 하지 않는 결과가 된다.
[
{ "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "test", "path": "/a/b/c", "value": "C" }
]
Bryan & Nottingham Standards Track [Page 8]
RFC 6902 JSON Patch April 2013
6. IANA 고려사항
JSON Patch 문서의 인터넷 미디어 타입은 application/
json-patch+json이다.
타입 이름: application
하위 타입 이름: json-patch+json
필수 매개변수: 없음
선택 매개변수: 없음
인코딩 고려사항: binary
보안 고려사항:
Section 7의 보안 고려사항을 참조한다.
상호운용성 고려사항: N/A
공개된 명세:
RFC 6902
이 미디어 타입을 사용하는 애플리케이션:
JSON 문서를 조작하는 애플리케이션.
추가 정보:
매직 넘버: N/A
파일 확장자: .json-patch
Macintosh 파일 타입 코드: TEXT
추가 정보를 위한 연락 담당자 및 이메일 주소:
Paul C. Bryan <pbryan@anode.ca>
사용 목적: COMMON
사용 제한: 없음
저자: Paul C. Bryan <pbryan@anode.ca>
변경 관리자: IETF
Bryan & Nottingham Standards Track [Page 9]
RFC 6902 JSON Patch April 2013
7. 보안 고려사항
이 명세는 JSON [RFC4627] 및 JSON-Pointer [RFC6901]와 동일한 보안
고려사항을 가진다.
몇몇 오래된 웹 브라우저는 루트가 배열인 임의의 JSON 문서를
로드하도록 강제될 수 있으며, 이로 인해 접근이 인증되어 있더라도
민감한 정보를 포함한 JSON Patch 문서가 공격자에게 노출될 수 있는
상황이 발생할 수 있다. 이는 Cross-Site Request Forgery(CSRF)
공격으로 알려져 있다 [CSRF].
그러나 이러한 브라우저는 널리 사용되지 않는다(작성 당시
시장의 1% 미만에서 사용되는 것으로 추정된다). 그럼에도 이러한
공격을 우려하는 게시자는 HTTP GET으로 그러한 문서를 제공하지
않도록 권고된다.
8. 감사의 말
다음 개인들은 이 명세에 아이디어, 피드백 및 문구를 제공했다.
Mike Acar, Mike Amundsen, Cyrus Daboo, Paul Davis, Stefan Koegl,
Murray S. Kucherawy, Dean Landolt, Randall Leeds, James Manger,
Julian Reschke, James Snell, Eli Stevens, and Henry S. Thompson.
JSON Patch 문서의 구조는 XML Patch 문서 명세 [RFC5261]의
영향을 받았다.
9. 참고문헌
9.1. 규범적 참고문헌
[RFC2119] Bradner, S., "요구 수준을 나타내기 위해 RFC에서
사용하는 핵심 단어", BCP 14, RFC 2119, March 1997.
[RFC4627] Crockford, D., "JavaScript Object Notation(JSON)을 위한
application/json 미디어 타입", RFC 4627, July 2006.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901,
April 2013.
9.2. 참고용 참고문헌
[CSRF] Barth, A., Jackson, C., and J. Mitchell, "Cross-Site
Request Forgery에 대한 견고한 방어", ACM Conference
on Computer and Communications Security, October 2008,
<http://seclab.stanford.edu/websec/csrf/csrf.pdf>.
Bryan & Nottingham Standards Track [Page 10]
RFC 6902 JSON Patch April 2013
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5261] Urpalainen, J., "XPath 선택자를 활용한 Extensible
Markup Language(XML) 패치 작업 프레임워크", RFC 5261,
September 2008.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, March 2010.
Bryan & Nottingham Standards Track [Page 11]
RFC 6902 JSON Patch April 2013
부록 A. 예제
A.1. 객체 멤버 추가
예제 대상 JSON 문서:
{ "foo": "bar"}
JSON Patch 문서:
[
{ "op": "add", "path": "/baz", "value": "qux" }
]
결과 JSON 문서:
{
"baz": "qux",
"foo": "bar"
}
A.2. 배열 요소 추가
예제 대상 JSON 문서:
{ "foo": [ "bar", "baz" ] }
JSON Patch 문서:
[
{ "op": "add", "path": "/foo/1", "value": "qux" }
]
결과 JSON 문서:
{ "foo": [ "bar", "qux", "baz" ] }
A.3. 객체 멤버 제거
예제 대상 JSON 문서:
{
"baz": "qux",
"foo": "bar"
}
Bryan & Nottingham Standards Track [Page 12]
RFC 6902 JSON Patch April 2013
JSON Patch 문서:
[
{ "op": "remove", "path": "/baz" }
]
결과 JSON 문서:
{ "foo": "bar" }
A.4. 배열 요소 제거
예제 대상 JSON 문서:
{ "foo": [ "bar", "qux", "baz" ] }
JSON Patch 문서:
[
{ "op": "remove", "path": "/foo/1" }
]
결과 JSON 문서:
{ "foo": [ "bar", "baz" ] }
A.5. 값 교체
예제 대상 JSON 문서:
{
"baz": "qux",
"foo": "bar"
}
JSON Patch 문서:
[
{ "op": "replace", "path": "/baz", "value": "boo" }
]
결과 JSON 문서:
{
"baz": "boo",
"foo": "bar"
}
Bryan & Nottingham Standards Track [Page 13]
RFC 6902 JSON Patch April 2013
A.6. 값 이동
예제 대상 JSON 문서:
{
"foo": {
"bar": "baz",
"waldo": "fred"
},
"qux": {
"corge": "grault"
}
}
JSON Patch 문서:
[
{ "op": "move", "from": "/foo/waldo", "path": "/qux/thud" }
]
결과 JSON 문서:
{
"foo": {
"bar": "baz"
},
"qux": {
"corge": "grault",
"thud": "fred"
}
}
A.7. 배열 요소 이동
예제 대상 JSON 문서:
{ "foo": [ "all", "grass", "cows", "eat" ] }
JSON Patch 문서:
[
{ "op": "move", "from": "/foo/1", "path": "/foo/3" }
]
결과 JSON 문서:
{ "foo": [ "all", "cows", "eat", "grass" ] }
Bryan & Nottingham Standards Track [Page 14]
RFC 6902 JSON Patch April 2013
A.8. 값 테스트: 성공
예제 대상 JSON 문서:
{
"baz": "qux",
"foo": [ "a", 2, "c" ]
}
성공적인 평가 결과가 되는 JSON Patch 문서:
[
{ "op": "test", "path": "/baz", "value": "qux" },
{ "op": "test", "path": "/foo/1", "value": 2 }
]
A.9. 값 테스트: 오류
예제 대상 JSON 문서:
{ "baz": "qux" }
오류 조건을 발생시키는 JSON Patch 문서:
[
{ "op": "test", "path": "/baz", "value": "bar" }
]
A.10. 중첩 멤버 객체 추가
예제 대상 JSON 문서:
{ "foo": "bar" }
JSON Patch 문서:
[
{ "op": "add", "path": "/child", "value": { "grandchild": { } } }
]
Bryan & Nottingham Standards Track [Page 15]
RFC 6902 JSON Patch April 2013
결과 JSON 문서:
{
"foo": "bar",
"child": {
"grandchild": {
}
}
}
A.11. 인식되지 않는 요소 무시
예제 대상 JSON 문서:
{ "foo": "bar" }
JSON Patch 문서:
[
{ "op": "add", "path": "/baz", "value": "qux", "xyz": 123 }
]
결과 JSON 문서:
{
"foo": "bar",
"baz": "qux"
}
A.12. 존재하지 않는 대상에 추가
예제 대상 JSON 문서:
{ "foo": "bar" }
JSON Patch 문서:
[
{ "op": "add", "path": "/baz/bat", "value": "qux" }
]
이 JSON Patch 문서를 위의 대상 JSON 문서에 적용하면 오류가
발생한다(따라서 적용되지 않는다). 이는 "add" 작업의 대상 위치가
문서의 루트도, 기존 객체의 멤버도, 기존 배열의 멤버도 참조하지
않기 때문이다.
Bryan & Nottingham Standards Track [Page 16]
RFC 6902 JSON Patch April 2013
A.13. 유효하지 않은 JSON Patch 문서
JSON Patch 문서:
[
{ "op": "add", "path": "/baz", "value": "qux", "op": "remove" }
]
이 JSON Patch 문서는 "add" 작업으로 취급될 수 없다. 나중에
나오는 "op":"remove" 요소를 포함하기 때문이다. JSON은 객체 멤버
이름이 고유해야 한다는 "SHOULD" 요구사항을 가지며, 중복에 대한
표준 오류 처리는 없다.
A.14. ~ 이스케이프 순서
예제 대상 JSON 문서:
{
"/": 9,
"~1": 10
}
JSON Patch 문서:
[
{"op": "test", "path": "/~01", "value": 10}
]
결과 JSON 문서:
{
"/": 9,
"~1": 10
}
A.15. 문자열과 숫자 비교
예제 대상 JSON 문서:
{
"/": 9,
"~1": 10
}
Bryan & Nottingham Standards Track [Page 17]
RFC 6902 JSON Patch April 2013
JSON Patch 문서:
[
{"op": "test", "path": "/~01", "value": "10"}
]
이는 테스트가 실패하므로 오류가 된다. 문서 값은 숫자이지만,
테스트 대상 값은 문자열이기 때문이다.
A.16. 배열 값 추가
예제 대상 JSON 문서:
{ "foo": ["bar"] }
JSON Patch 문서:
[
{ "op": "add", "path": "/foo/-", "value": ["abc", "def"] }
]
결과 JSON 문서:
{ "foo": ["bar", ["abc", "def"]] }
저자 주소
Paul C. Bryan (editor)
Salesforce.com
Phone: +1 604 783 1481
EMail: pbryan@anode.ca
Mark Nottingham (editor)
Akamai
EMail: mnot@mnot.net
Bryan & Nottingham Standards Track [Page 18]