Pratica "migliore" per una risposta POST riposante

Quindi niente di nuovo qui sto solo cercando di ottenere alcuni chiarimenti e non riesco a trovarne nessuno in altri post.

Sto creando una nuova risorsa in modo irrequieto, ad esempio:

/books (POST)

con un corpo:

{
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

So che dovrei restituire un 201 (creato) con un'intestazione Location della nuova risorsa:

Location: /books/12345

La domanda a cui non riesco a rispondere da solo è cosa dovrebbe restituire il server nel corpo.

Ho spesso fatto questo tipo di risposta:

{
  id: 12345,
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

L'ho fatto per un paio di motivi:

1. Ho scritto api per framework front-end come angularjs. Nel mio caso particolare sto usando risorse angolari e spesso ho bisogno solo dell'id per la risorsa per individuarlo. Se non restituissi l'id nel corpo della risposta, dovrei analizzarlo dall'intestazione Location.
2. In un GET di tutti i libri di solito restituisco l'intero oggetto non solo l'ID. In questo senso il mio codice cliente non deve differenziare da dove ottenere l'id (intestazione o corpo della posizione).

Ora so di essere davvero nell'area grigia qui, ma la maggior parte delle persone sta dicendo che restituire l'intera risorsa è una pratica "cattiva". Ma cosa succede se il server modifica / aggiunge informazioni alla risorsa. Aggiunge sicuramente l'id, ma potrebbe anche aggiungere altre cose come un timestamp. Nel caso in cui non restituisca l'intera risorsa, è davvero meglio fare un POST, restituire l'id, quindi fare in modo che il client esegua un GET per ottenere la nuova risorsa.

Restituire l'intero oggetto su un aggiornamento non sembrerebbe molto rilevante, ma difficilmente riesco a capire perché restituire l'intero oggetto quando viene creato sarebbe una cattiva pratica in un normale caso d'uso. Ciò sarebbe utile almeno per ottenere facilmente l'ID e per ottenere i timestamp, se pertinenti. Questo è in realtà il comportamento predefinito ottenuto durante i ponteggi con Rails.

Non vedo davvero alcun vantaggio nel restituire solo l'ID e fare una richiesta GET dopo, per ottenere i dati che potresti avere con il tuo POST iniziale.

Comunque, purché la tua API sia coerente, penso che dovresti scegliere il modello che si adatta meglio alle tue esigenze. Non esiste un modo corretto per creare un'API REST, imo.

La restituzione del nuovo oggetto si adatta al principio REST di "Interfaccia uniforme - Manipolazione delle risorse tramite rappresentazioni". L'oggetto completo è la rappresentazione del nuovo stato dell'oggetto che è stato creato.

C'è un riferimento davvero eccellente per la progettazione dell'API, qui: Best practice per la progettazione di un'API RESTful pragmatica

Include una risposta alla tua domanda qui: Aggiornamenti e creazione dovrebbero restituire una rappresentazione delle risorse

Dice:

Per impedire a un consumatore di API di dover premere nuovamente l'API per una rappresentazione aggiornata, fare in modo che l'API restituisca la rappresentazione aggiornata (o creata) come parte della risposta.

Mi sembra ben pragmatico e si adatta al principio REST che ho menzionato sopra.