Prima di tutto, cercare di evitare di confondere i metodi HTTP con le operazioni CRUD. Credo che sia la principale fonte di confusione in REST. I metodi HTTP non si traducono in operazioni CRUD in modo pulito come quello. Ho una risposta dettagliata qui:
S3 REST API and POST method
In breve.
- POST è il metodo utilizzato per qualsiasi operazione che non è standardizzata da HTTP e sottopone il carico utile all'URI di destinazione.
- PUT viene utilizzato per sostituire completamente la risorsa al presente URI e sottopone il carico utile al servizio stesso.
- PATCH è per aggiornamenti idempotenti parziali, con una differenza tra lo stato corrente e quello desiderato.
- DELETE viene utilizzato per eliminare la risorsa.
- GET viene utilizzato per recuperare la risorsa.
Ora, sul lato backend, prova a pensare alle risorse REST più come una macchina a stati in cui è possibile utilizzare i metodi per forzare una transizione piuttosto che un oggetto con metodi. In questo modo focalizzi l'implementazione sulla risorsa stessa, non sull'interazione con il protocollo. Ad esempio, è possibile modificare direttamente gli attributi di un oggetto dal carico utile del metodo e quindi disporre di un metodo chiamato per rilevare la transizione necessaria.
Ad esempio, si può pensare a una mela come a tre stati, intera, affettata, affettata e spremuta. Transizione tra stati utilizzando il comportamento standardizzato dei metodi.
Per esempio:
GET /apple
{"state": "whole",
"self": "/apple"}
poi si desidera affettarlo. Si può fare qualcosa di simile:
PUT /apple
{"state": "sliced"}
Oppure si può fare qualcosa di simile:
PATCH /apple
{"from_state": "whole", "to_state": "sliced"}
O anche qualcosa di simile:
POST /apple
{"transition": "slice"}
L'idea è che le implementazioni possono essere sufficiente che generici non devi preoccuparti troppo dell'abbinamento della risorsa ai metodi HTTP.
- La versione PUT è idempotente, quindi i client possono scegliere di usarlo quando hanno bisogno di idempotence.
- La versione PATCH garantisce che il client conosca lo stato corrente e stia tentando una transizione valida.
- La versione POST è la più flessibile, puoi fare tutto ciò che vuoi, ma deve essere documentato in dettaglio. Non puoi semplicemente supporre che i tuoi clienti sapranno come funziona il metodo.
Finché l'implementazione della risorsa capisce che quando apple.state viene modificato in qualche altra cosa che dovrebbe rilevare ciò che è avvenuto il cambiamento e di eseguire la transizione adeguata, si sono completamente disaccoppiati dal protocollo. Non importa quale metodo è stato usato.
Credo che questa sia la soluzione più elegante e rende tutto più facile da gestire dal lato back-end. Puoi implementare i tuoi oggetti senza preoccuparti troppo del protocollo. Finché gli oggetti possono essere trasferiti tra stati, possono essere utilizzati da qualsiasi protocollo in grado di effettuare tali transizioni.
'PUT/apple/color newColor = red', o' PUT/apple cmd = updateColor & newColor = red', si concentra sulla combinazione di uri e argomenti di queste due API, quale è migliore (o più RESTful)? – dastan
Nessuno dei due è RESTful. Il primo richiederebbe che l'intero carico utile fosse la rappresentazione di una risorsa di colore. Il secondo implica il comando updateColor che viene eseguito dalla risorsa apple stessa. Posso vedere 'PUT/apple/color' essere RESTful se 'red' è l'intero payload con il tipo di media dell'attributo apple.color, ma la seconda opzione è irreparabile. –