Indica se incorporare risorse collegate nell'API REST

Probabilmente dovresti optare per l'opzione 1, ma reso più RESTful. Potrebbe anche aver senso fornire qualcosa come l'opzione 3/4. Non c'è nulla che ti costringa a sceglierne solo uno.

Tuttavia, ciò che dovresti fare è sostituire gli id con link . Invece di avere un "sender_id", dovresti avere un puntamento URI a quella risorsa utente. Nota come questo significa che non ho bisogno di sapere quale URI aggiungere "sender_id" o come formattare. Sfortunatamente, JSON non ha un tipo per i collegamenti. Dovrai esaminare i formati hypermedia incorporati in JSON , ad es. HAL o JSON-LD.

Ora hai ragione che se voglio recuperare il record, ho bisogno di fare due richieste. La buona notizia, tuttavia, è che quelle richieste saranno memorizzate nella cache dal meccanismo normale di HTTP. Una rete di distribuzione dei contenuti può persino memorizzare nella cache le risorse tra gli utenti riducendo il carico sui server e la latenza per gli utenti. Naturalmente, non mi è precluso avere una risorsa che restituisce tutti gli utenti oi dati per tutti gli utenti che hanno fornito un elenco di URI utente in modo da poter effettuare richieste batch. Potresti considerare OData come un mezzo organizzato per fornire tali funzionalità di query, ma puoi certamente fare qualcosa di più semplice. Ad esempio, quando si restituiscono i messaggi, è anche possibile aggiungere un collegamento a, ad esempio, "contatti recenti" con i dati espansi per tutti gli utenti nell'elenco corrente di messaggi. Nota come dico di fornire un link e non aggiungere una risorsa messages/users/ . Potresti aggiungere una tale risorsa, ma non avrei bisogno di conoscere la tua struttura URI per trovarla. Questo mi rende più facile e ti consente di cambiare i tuoi URI in futuro senza rompere i consumatori.

A volte ci saranno garanzie transazionali che vorrete imporre. Ad esempio, in quanto sopra, è possibile ottenere i messaggi, quindi richiedere i contatti recenti e tale elenco potrebbe differire dall'elenco degli URI del mittente presenti nei messaggi a causa di una condizione di competizione. Nei casi in cui è importante garantire quel tipo di atomicità, è necessario incorporare le risorse. Alcuni dei formati hypermedia cui ho fatto riferimento sopra forniscono un meccanismo per questo. Di solito, queste situazioni corrisponderanno naturalmente a una nuova risorsa. Ricorda, tu non hai bisogno di una corrispondenza di 1-1 tra risorse e "entità" o qualsiasi altra cosa. In effetti, una corrispondenza di tipo 1-1 probabilmente significa che stai facendo qualcosa di sbagliato. Nel complesso, tuttavia, dovresti cercare di minimizzare i punti che richiedono tali garanzie transazionali. Nell'esempio sopra, non sarebbe necessario, poiché anche se mancasse un mittente dall'elenco di "contatti recenti", potrei semplicemente richiedere le loro informazioni individualmente.

Penso che dipenda anche dai bisogni. Supponiamo che l'app client mostri un elenco di 100 elementi e che ogni messaggio debba visualizzare il mittente. Se inseriamo tutti i dati richiesti nel JSON (cioè l'ID del mittente e il nome del mittente), facciamo una sola richiesta. Se invece ci sono collegamenti ai mittenti, abbiamo 101 richieste. Non dirmi che questo è efficiente:)

Ma sono d'accordo sul fatto che gli URI siano una buona pratica, ad esempio quando si implementa una funzionalità quando l'utente può fare clic sul nome del mittente e vedere maggiori informazioni su di lui. Quindi la mia opinione su questa struttura sarebbe la seguente:

[
    {
        "id": 12345,
        "sender": {
            "link": "www.api.example.com/users/16",
            "name": "John Smith"
        },
        "text": "Hello, world!"
    }
]