TL; DR suggerirei di implementare una combinazione del secondo ( PUT /invoices/{id} ) e del terzo ( PATCH /invoices/{id}/ ) suggerimento.
Diamo un'occhiata alla prima parte che è l'URI. Possono esistere molti standard su come si possono formare gli uri in base alle linee guida seguite da un progetto o squadra. Tuttavia, per semplicità una delle regole del pollice che preferirei mantenere è che un endpoint della risorsa data dovrebbe idealmente avere un end-point di matching corrispondente (eccetto se l'endpoint termina con un nome di operazione).
Per chiarire il mio punto, PUT /invoices/{id}/status - questo suggerimento dovrebbe avere senso (o rendere le cose intuitive per l'utente api) quando hai anche un GET /invoices/{id}/status equivalente per esso, che credo non sarebbe il caso renderà il tuo sforzo di sviluppo solo più ingombrante. Se per caso vuoi esporre selettivamente gli attributi in "GET", ti suggerisco comunque di implementare GraphQL per "GET" piuttosto che implementare il tuo standard e andare con "PATCH" per gli aggiornamenti. (Inoltre, solo una piccola raccomandazione, idealmente vorresti mantenere attributi come status in invoice come di sola lettura in quanto rappresentano lo stato della fattura e dovrebbero idealmente essere modificati tramite alcuni endpoint specifici dell'operazione come POST /invoices/{id}/send anziché tramite un'operazione PUT .
Venendo verso gli altri suggerimenti menzionati, PUT /invoices/{id} e PATCH /invoices/{id}/ , la decisione si basa sul fatto che l'API sia esposta internamente o esternamente perché altrimenti, entrambi sono standard HTTP validi.
- Se esposto esternamente, suggerirei di implementare sia PUT che PATCH perché molti dei consumatori dell'API potrebbero non avere un supporto rilevante per l'implementazione di PATCH o potrebbero considerarlo un po 'troppo difficile da implementare
in modo impeccabile, a seconda degli sviluppatori che hanno e in tale scenario preferiresti dare loro entrambe le opzioni.
- Se l'API è strettamente per uso interno, in questi casi è possibile scegliere di andare esclusivamente con PATCH per ottenere il vantaggio di ridurre il carico utile non necessario nella richiesta di aggiornamento.