REST - come progettare un URI con chiavi composite?

Question

Ho una domanda su come progettare un URI di risorse con chiavi composite.

Ho una risorsa denominata trasporto che ha 4 chiavi/id: ID partner, codice postale iniziale, codice postale finale e peso.

In realtà la mia risorsa è stata progettata per avere un ID incrementale generato da database, ma questo approccio non è così buono per i consumatori API, ad esempio, se un consumatore/partner ha bisogno di aggiornare un informazioni merci che devono fare:

?

GET merci initialZipcode = {valore} & finalZipcode = {valore} & peso = {valore}

la risposta dell'operazione di cui sopra sarebbe l'ID di merci, così alla fine si può aggiornare informazioni:

PUT merci/{ID}

L'ID partner è implicito dal meccanismo di autenticazione.

Per me sembra strano costringere i partner a ottenere l'ID di trasporto prima di aggiornare le informazioni.

Quindi la mia domanda è: come posso progettare questo URI?

PUT merci/initialZipcode/{valore}/finalZipCode/{valore}/peso/{valore}

ho io a prendere in considerazione il progetto di cui sopra?

Un'altra domanda: è una buona pratica incorporare l'ID partner nel meccanismo di autenticazione? Conosco i pro (facile per i consumatori) e contro (cache, impossibilità di condividere un URI, ecc.), Ma non so se generalmente è una buona o cattiva pratica.

Grazie!

Answer 1

Non c'è niente di sbagliato con

PUT freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE} 

parametri di query vengono parte dell'identificazione risorsa troppo.

I parametri del percorso sono utili per definire le risorse che si adattano bene in una gerarchia. Nel tuo caso la risorsa non si adatta bene in una gerarchia, quindi non provare a spremere i parametri in segmenti di percorso.

L'unica sfida è cosa fare quando il client riordina l'ordine dei parametri della query. La tratti come la stessa risorsa o lo hai 404? Se non stai memorizzando nella cache le risposte GET, allora probabilmente non importa.

Se hai fornito al tuo cliente un modello URI da compilare, ci sono meno possibilità che ti forniscano i parametri nell'ordine sbagliato.

---

L'altra opzione, se si va con la tua proposta originale è che il GET restituisce un reindirizzamento e una posizione di testa a un URI con l'ID del trasporto. per esempio.

GET freight?initialZipcode={VALUE}&finalZipcode={VALUE}&weight={VALUE} 
=> 
302 See Other 
Location: freight/1232321322 

In questo modo, il cliente non deve sapere nulla l'ID del trasporto, si può semplicemente prendere l'intestazione posizione, e seguire il reindirizzamento di fare un GET, o fare un PUT direttamente contro qualunque URI è nell'intestazione Location.Ciò significa che se decidi che non ti piace esporre l'ID in futuro, puoi cambiare l'URI senza rompere alcun client.