altri messi vs POST con UUID

Question

Se sto usando un UUID di identificare il soggetto come parte della mia URI del mio riposo endpoint:

/entities/<uuid>/ 

e che UUID è generato dal cliente durante la creazione di nuove entità, è Esiste una buona pratica per quanto riguarda l'utilizzo di PUT rispetto a POST? In altre parole, il UUID viene generato dal client anziché dal server.

Se dovessi utilizzare PUT, è previsto che il payload del messaggio contenga anche lo UUID? In questo caso sia il messaggio che l'URI che identificano l'entità conterranno lo UUID.

Per spec, si veda: il REST RFC

Answer 1

Dal momento che (il client) conosce già l'UUID, direi PUT è la migliore pratica, e non c'è bisogno di inserire UUID nel payload. Certo, vs POST è alquanto controverso e la lettura e la rilettura della RFC non lo chiariscono completamente. Ma penso che il precedente sia ortodossia.

Vedere PUT vs POST in REST per una bella discussione.

Answer 2

La differenza principale tra POST e PUT:

POST viene utilizzato per aggiungere nuove entità. POST è non idempotente. Ciò significa che se invii dieci volte la richiesta POST, creerai dieci diverse entità. Di solito si dovrebbe ottenere il codice di risposta 201 (creato) alla richiesta POST accoppiato con l'intestazione di posizione che punta all'URL della risorsa appena creata. Nel tuo caso suggerisco nella quale inserire l'URL sthm come

POST /entities/ HTTP/1.1 
Content-Type: application/json 
{ 
    UUID: <UUID>.. 
    OtherStuff: ... 
} 

Risposta:

HTTP/1.1 201 Created 
Location: http://www.myREST/entities/<uuid>/ 

PUT richiesta viene utilizzato per modificare lo stato esistente. PUT è idempotente. Di solito riceverai 200 (OK) codice di risposta.

È necessario contenere UUID nel carico utile PUT/POST. UUID fa parte della rappresentazione della tua risorsa. PUT e POST trasferiscono entrambe la rappresentazione sul server REST per modificare/aggiungere lo stato della risorsa.

BTW non si deve usare il termine URI in REST. L'URI è sthm che potrebbe non avere una rappresentazione, sebbene l'URL abbia sempre una rappresentazione.

Answer 3

Comprendere la differenza tra PUT e POST.

PUT è pensato per sostituire la risorsa (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6) indicata dall'URI con una nuova. Ed è idempotente, cioè quante volte lo invochi con lo stesso carico utile, il risultato è lo stesso; renderà la stessa risorsa disponibile attraverso l'URI.

Quindi, se la risorsa non è già presente, ne viene creata una nuova. Anche in questo caso il risultato è lo stesso, cioè renderà disponibile la stessa risorsa attraverso l'URI.

POST si intende creare una sottorisorsa (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5) alla risorsa indicata dall'URI.Se la risorsa è una lista, aggiungerà un elemento ad essa. Se è un oggetto allora dovrebbe aggiungere qualcosa all'elemento, un attributo può essere.

Quindi, idealmente se l'elemento indicato dall'URI non è disponibile, dovrebbe essere una condizione di errore. Può essere un "404". Il POST consiste nell'aggiungere a una risorsa esistente.

Venendo alla tua domanda, è meglio usare POST con "/ entities /" come URI come da descrizione sopra. Non si dovrebbe utilizzare un UUID di risorse inesistente nell'URI con il metodo POST. Se stai usando PUT quindi usa "/ entities /".

POST /entities/ HTTP/1.1 
Content-Type: application/json 
{ 
    UUID: <UUID>.. 
    OtherStuff: ... 
} 

PUT /entities/<UUID> HTTP/1.1 
Content-Type: application/json 
{ 
    UUID: <UUID>.. 
    OtherStuff: ... 
} 

risposta dovrebbe essere lo stesso

HTTP/1.1 201 Created 
Location: http://www.examples.com/entities/<uuid>/ 

sebbene PUT è idempotente ma se il metodo PUT viene riutilizzato allora dovrebbe usare 200 o 204 in risposta.

La seconda domanda: idealmente i dettagli della risorsa completa devono essere nel payload PUT anziché solo nell'URI.