JSON REST Risposte e oggetti incorporati

Come per molti problemi di progettazione, la risposta è "dipende".

Nella maggior parte dei casi devi trovare un equilibrio tra:

1. Grande risposta: incorpora tutto, anche se alcuni client non lo usano
2. Molte richieste: non incorporare nulla e lasciare che i client facciano una richiesta in più per ogni risorsa aggiuntiva di cui hanno bisogno.

Non penso che uno di questi sia "più corretto" dell'altro.

Esistono alcuni standard come API JSON e HAL questo tentativo (tra le altre cose) di risolvere questo problema. Entrambi hanno il concetto di risorse "incluse" (o incorporate) richieste dal cliente, ad es. per API JSON

Se richiedi GET /articles , riceverai:

{
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON API paints my bikeshed!",
      "body": "The shortest article. Ever.",
      "created": "2015-05-22T14:56:29.000Z",
      "updated": "2015-05-22T14:56:28.000Z"
    },
    "relationships": {
      "author": {
        "data": {"id": "42", "type": "people"},
        "links": {
          "self": "http://example.com/articles/1/author"
        }
      }
    }
  }]
}

E potresti anche fare GET /articles?include=author

{
  "data": [{
    "type": "articles",
    "id": "1",
    "attributes": {
      "title": "JSON API paints my bikeshed!",
      "body": "The shortest article. Ever.",
      "created": "2015-05-22T14:56:29.000Z",
      "updated": "2015-05-22T14:56:28.000Z"
    },
    "relationships": {
      "author": {
        "data": {"id": "42", "type": "people"},
        "links": {
          "self": "http://example.com/articles/1/author"
        }
      }
    }
  }],
  "included": [
    {
      "type": "people",
      "id": "42",
      "attributes": {
        "name": "John",
        "age": 80,
        "gender": "male"
      }
    }
  ]
}

Che aggiunge una chiave "inclusa" che contiene più risorse. In questo modo il cliente può decidere per ogni caso d'uso.

Ovviamente, questo pone un ulteriore onere nel client per analizzare la risposta poiché è più complessa di semplici strutture di dati (ci sono liberia per questo).

Ecco alcune letture utili:

• Livello di maturità Richardson
• tesi di Roy Fielding

Il secondo approccio di "Embedded Objects" è più esteso e amp; utile quando si lavora con strutture JSON complesse. Una struttura JSON potrebbe contenere uno o più dei seguenti tipi : stringa, numero, oggetto, matrice, vero, falso o null . Essendo Object una struttura JSON, significa che un JSON è pensato come struttura complessa di oggetti coppia-valore-chiave annidati come richiesto. Un'altra cosa, ripetere lo stesso URL di base dell'esempio SWAPI non è considerata una buona pratica.