항목을 게시 할 때 여러 가지 값을 정의 할 수있는 필드가있는 API를 설명하고 싶지만 특정 방식으로 필드에 출력해야합니다.JSON Hyper-Schema : GET 및 POST에 대한 다른 스키마
예를 들어, {"name": "Task", "due": "2014-12-31"}
또는 {"name": "Task", "due": {"$date": 1419984000000}}
과 같이 항목을 만들거나 업데이트 할 수있는 API를 설명하고 싶지만 첫 번째 방법으로는 API에서만 반환됩니다.
POST/PUT의 스키마 그러므로 수 :
이{
"type": "object"
"properties": {
"name": {
"type": "string"
},
"due": {
"type": "string",
"format": "date"
}
}
}
그것은 API의 소비자에게 좋은 것 :
GET을 통해 액세스에 대한 스키마 반면{
"type": "object"
"properties": {
"name": {
"type": "string"
},
"due": {
"oneOf": [
{
"type": "string",
"format": "date"
},
{
"type": "object",
"properties": {
"$date": {
"type": "number"
}
},
"required": ["$date"],
"additionalProperties": false
}
]
}
}
}
훨씬 간단 할 것 그들 모두가 아니라 한 가지 가능한 출력 방법을 설명하면된다는 것을 알 수 있습니다.
JSON Hyper-Schema의 컨텍스트 내에서 다른 스키마를 지정하는 데 허용되는 표준 접근 방식이 있습니까? "links"
속성을 통해 이러한 차이점을 지정하는 방법에 대해 생각해 보았습니다.하지만 "rel"
이 스키마를 정의 할 수 없다는 것을 알지 못합니다. 매우 비표준적인 것으로 보입니다.
이 항목은 항목을 생성하기위한 것이지 업데이트를위한 것이 아니며 업데이트는 표준에 없습니다. . – lyschoening
업데이트가 유효한 관계 유형이 아닙니다. 다음 RFC를 살펴보십시오. http://www.rfc-editor.org/rfc/rfc5988.txt CRUD 작업과 관계 유형이 혼란 스럽다고 생각합니다. "rel": "self"및 "href": "{id}"또는 업데이트 할 리소스를 식별하는 다른 URI가 필요합니다. – jruizaranguren
표준 관계가 [ "edit"] (http://tools.ietf.org/html/rfc5023#section-11.1)일지도 모르겠지만 그 역시 매우 모호합니다. "rel": "self"가 두 번 반복 될 수 있다면 (나는 할 수 있을지 모르겠다) "method"가있는 정상적인 것이있을 수 있습니다 : "GET"과 "POST"메소드로 업데이트하기. – lyschoening