-
Let’s start by acknowledging that is is a contested topìc. The answer is typically, “depends”.
-
Parece que el estandar **ideal **de una API REST con relaciones entre modelos serĂa HATEOAS, sumarizado aquĂ:
{
"links": {
"self": "<http://example.com/articles>",
"next": "<http://example.com/articles?page[offset]=2>",
"last": "<http://example.com/articles?page[offset]=10>"
},
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": "JSON:API paints my bikeshed!"
},
"relationships": {
"author": {
"links": {
"self": "<http://example.com/articles/1/relationships/author>",
"related": "<http://example.com/articles/1/author>"
},
"data": { "type": "people", "id": "9" }
},
"comments": {
"links": {
"self": "<http://example.com/articles/1/relationships/comments>",
"related": "<http://example.com/articles/1/comments>"
},
"data": [
{ "type": "comments", "id": "5" },
{ "type": "comments", "id": "12" }
]
}
},
- Lo pone muy fácil al cliente, salvo por tener que realizar múltiples peticiones para obtener un objeto compuesto.
-
Sin embargo, como siempre, sentido común: si un nested object se solicita a menudo con otro, pues incluimos la representación (incluso pudiendo especificar qué campos queremos que estén o no de ese nested resource).
-
JSON API también ofrece qué hacer con respecto a crear / modificar relaciones. Permite tanto PATCH como POST, donde el PATCH sustituye las relaciones y el POST las añade, escribiendo a las URIs nested… id:: f4bafa7c-4b98-44fa-abfc-414c11efe4a1
-
Existe también JSON Merge Patch, con reglas sobre cómo aplicar los patches:
- Best practice for partial updates in a RESTful service
-
If the provided merge patch contains members that do not appear within the target, those members are added.
-
If the target does contain the member, the value is replaced.
-
Null values in the merge patch are given special meaning to indicate the removal of existing values in the target.
-
- Best practice for partial updates in a RESTful service