Rest disegno uri per modificare lo stato della risorsa

Question

Ho una risorsa che può essere raggiunta all'URI /resources/{resource_identifier} e ha una proprietà 'status' che desidero essere accessibile. Ho pensato ad alcune opzioni per questo, che sarebbe il "migliore" o il "più RESTfull"?

azioni Opzione uno Append Onto l'URI e hanno il cliente POST a questi URI

/resources/{resource_identifier}/void  
/resources/{resource_identifier}/open  
/resources/{resource_identifier}/close 

questo sembra goffo però.

---

Opzione due Utilizzare un param query nella URI e avere il client PATCH a questi

/resources/{resource_identifier}?transition=void 
/resources/{resource_identifier}?transition=open 
/resources/{resource_identifier}?transition=close 

---

Opzione Tre Utilizzare il payload della richiesta e il client PUT

/resources/{resource_identifier} 

opzioni di payload:

{ ..., "status" :"void" } 
{ ..., "status" :"open" } 
{ ..., "status" :"close" } 

---

O forse qualcosa di completamente diverso?

Answer 1

La seconda opzione sembra migliore perché stai mantenendo la struttura url RESTful e non aggiungendo metodi in stile RPC alla fine.

Perché non basta fare questo:

PUT-/resources/:id e inviare i dati transition=void con la richiesta.

Si comporta nello stesso modo in cui verrebbe se si riceve una richiesta POST, basta estrarre i dati dal corpo della richiesta.

Answer 2

Perché non avere 'stato' come risorsa. Puoi gestirlo. Supponiamo anche che ci sia già uno "stato" creato come parte della creazione della risorsa {resource_identifier} e che esiste già un valore predefinito per lo stato.

Quindi la logica di business deve semplicemente "aggiornare" lo stato tramite la chiamata di riposo e pertanto è necessario utilizzare "PUT".

aggiornato Spostamento di stato per il Put-Corpo

PUT: /resources/{resource_identifier}/status/ 

Body: {void | open | close } 

Answer 3

La prima opzione non è chiaramente riposo; hai "azioni" nell'URI e stai usando POST, che è quello di creare una nuova risorsa, che chiaramente non stai tentando di fare.

Guardare solo il formato URI per ora. L'opzione due sta migliorando, ma le stringhe di query di tale natura sono più per che legge i dati. Niente ti impedisce davvero di farlo in questo modo. L'opzione tre ha il miglior formato URI, fa riferimento solo a quale risorsa si desidera fare riferimento nella richiesta.

Se ora consideriamo il metodo della richiesta. Nel mio libro, questo è piuttosto semplice, presumo che lo stato sia solo un campo di questa risorsa, e quindi se si sta solo effettuando un aggiornamento parziale, si sta procedendo al patching della risorsa, e quindi il metodo da utilizzare è PATCH. Nel caso in cui lo 'stato' sia l'unica proprietà, cambiare lo stato sta cambiando completamente la risorsa e quindi PUT sarebbe accettabile; ma dubito che sia davvero così.

Allo stato attuale, l'URI della terza opzione, combinato con l'uso di PATCH è probabilmente l'opzione migliore.

PATCH /resources/{resource_identifier} 

{ "status" :"close" } 

Naturalmente, si potrebbe anche combinare questo con il concetto di esporre attributi specifici tramite il proprio URI come se fossero una risorsa nel loro diritto. Francamente, non mi piace, perché sembra piuttosto strano e funziona solo per un attributo alla volta. Eppure, se questo è quello che si voleva utilizzare, si potrebbe avere qualcosa di simile:

PUT /resources/{resource_identifier}/status 

close 

---

Tenete a mente, non c'è modo "giusto" di fare REST, solo modi "not bad". È uno stile, non una regola.

Suggerisco anche di considerare che essere in grado di prendere molti formati è una caratteristica desiderabile, in generale. In quanto tale, la prima opzione tende ad essere più facile con cui lavorare. Puoi prendere JSON, come nell'esempio, o scambiarlo con XML <status>close</ status>, o con una coppia di valori chiave semplice status=closed ecc.