API REST - proprietà omesse nella richiesta POST: come devono essere gestite?

Naviga le tue risposte
4

Dato il seguente scenario:

  1. Entità insegnante 

    {  
"id": "1234",  
"name": "Mr. Didactic",  
"Subject": "History",  
"Classroom": "1A"  
}

  2. Endpoint dell'API REST: 

    /teacher/id/1234

Diciamo che invio una richiesta POST (aggiornamento) all'endpoint con questo corpo della richiesta: 

{  
"id": "1234",  
"name": "Mr. Didactic",  
"Subject": "History"
}

Come dovrebbe essere gestito / interpretato? È richiesto che Classroom sia impostato su null / empty?

O è intatto, cioè non fare nulla per Classroom, non fa parte della richiesta?

O c'è un altro modo di interpretarlo? Cosa ci si aspetta o sono le migliori pratiche qui?

    
posta richard 11.02.2016 - 23:58
fonte

2 risposte

6

Per una richiesta di aggiornamento (POST), un campo omesso non deve essere modificato. Per cancellare un campo dal suo valore, dovrebbe essere menzionato nella richiesta con il valore null o un valore normale per cambiare completamente il valore.
Nel tuo esempio, Classroom manterrà il valore 1A .

Per una richiesta di sostituzione documento (PUT), tutti i campi verranno cancellati e sostituiti con ciò che è all'interno della richiesta. Quindi, quando un campo viene omesso, verrà cancellato.
Nell'esempio, quando invii una richiesta PUT, Classroom sarà null .

Quando si utilizza il POST come richiesta di creazione, i campi omessi non saranno impostati, quindi Classroom rimane null .

Questo è almeno il modo specificato nella specifica jsonapi.org (una specifica per le risposte JSON sui servizi REST):

If a request does not include all of the attributes for a resource, the server MUST interpret the missing attributes as if they were included with their current values. The server MUST NOT interpret missing attributes as null values.

Altre specifiche, come OData, descrivono lo stesso comportamento. Ma se si documenta il comportamento implementato, è una tua scelta.

    
risposta data 12.02.2016 - 07:39
fonte
1

Penso che un buon esempio sia dato dallo standard OData, che chiama questi aggiornamenti differenziali .

Il POST dovrebbe essere usato per aggiungere risorse e PUT per sostituirli (PUT è idempotent ).

Quando PATCH non era uno standard, OData in realtà ha introdotto un metodo MERGE solo per affrontare la situazione nella tua domanda. OData 3.0 infatti dichiara MERGE obsoleto a favore del PATCH ufficiale.

Ad ogni modo, il POST dovrebbe impostare le proprietà mancanti su null, o cancellarle .

Vedi anche: Perché PUT HTTP non è autorizzato a eseguire aggiornamenti parziali in un'API REST?

    
risposta data 12.02.2016 - 08:14
fonte

Leggi altre domande sui tag

Java8: perché due metodi di composizione: e poi e componi? Funzione indipendente che chiama una funzione membro che cambia lo stato: una cattiva pratica?