Sono in grado di implementare un servizio REST (su una piattaforma Windows CE se ciò è importante) e ho iniziato a utilizzare IBM's general definitions di utilizzare POST per la creazione (INSERT) e PUT per l'aggiornamento.Verbi REST - la cui convenzione è "corretta"
Ora ho incontrato Sun's definitions che sono esattamente l'opposto. Quindi la mia domanda è: qual è la definizione "generalmente accettata"? O c'è anche uno?
Lo svantaggio dell'utilizzo di PUT per creare risorse è che il client deve fornire l'ID univoco che rappresenta l'oggetto che sta creando. Mentre solitamente è possibile per il client generare questo ID univoco, la maggior parte dei progettisti di applicazioni preferisce che i propri server (di solito attraverso i propri database) creino questo ID. Nella maggior parte dei casi vogliamo il nostro server per controllare la generazione di ID di risorsa. Quindi cosa facciamo? Possiamo passare a utilizzando POST anziché PUT.
Quindi: Put = UPDATE
Post = INSERT
+1 sul problema di creazione della chiave. –
Mentre questo dà una buona ragione per cui qualcuno potrebbe usare Messaggio per l'inserimento, in realtà non stabilire questo come standard. La generazione di ID non è un problema per chiunque usi Guids. Forse la risposta giusta è che non esiste uno standard generalmente accettato. È possibile utilizzare i verbi HTTP come meglio si adattano per implementare un servizio che rispetti i principi REST. –
Utilizziamo POST = Crea, PUT = Aggiorna.
Perché? Non c'è una ragione buona. Dovevamo sceglierne uno, ed è quella la scelta che ho fatto.
Modifica. Guardando ad altre risposte, mi rendo conto che il problema della creazione della chiave potrebbe prendere la decisione.
Inviamo nuove voci e restituiamo un oggetto JSON con la chiave generata. Sembra che questo sia un adattamento migliore per la semantica POST generalmente accettata.
METTIAMO alle voci esistenti con un URI completo che identifica l'oggetto.
In pratica basta scegliere uno e correre con esso allora. Che quello che (involontariamente) ha fatto - volevo solo fare in modo che non avevo intenzione di confondere tutti i miei clienti, scegliendo l'inverso della pratica comune. – ctacke
"clienti"? Si prega di aggiornare la domanda per spiegare chi potrebbe essere confuso. –
Per "cliente" intendo se creo questo servizio per il mio cliente (chi sta pagando per il lavoro, non per l'app del consumatore di servizi), poi va avanti e desidera estenderlo e aggiungere altri servizi che non finiscono sentendo che il mio uso di POST/PUT è arretrato rispetto a tutto ciò che vedono come esempi. – ctacke
PUT può essere utilizzato per la creazione quando il server concede il controllo client su una parte del suo spazio URI. Ciò equivale alla creazione di file in un file system: quando si salva in un file che non esiste ancora, lo si crea e, se il file esiste, il risultato è un aggiornamento.
Tuttavia, PUT non ha la capacità di un intento implicito del cliente. Considera di effettuare un ordine: se hai inserito/ordini/mio-nuovo-ordine, il significato può sempre essere aggiornato con la risorsa identificata da/orders/my-new-order mentre POST/orders/può significare 'effettuare un nuovo ordine' se la risorsa che accetta POST ha la semantica appropriata.
IOW, se si desidera ottenere qualcosa come effetto collaterale della creazione della nuova risorsa, è necessario utilizzare POST.
gen
La ragione per usare POST INSERT e PUT come UPDATE è che POST è l'unico nonidempotent e pericoloso funzionamento secondo HTTP. Idempotente significa che non importa quante volte si applica l'operazione, il risultato è sempre lo stesso. In SQL INSERT è l'unica operazione non-dipendente in modo che dovrebbe essere mappata su POST. UPDATE è idempotente in modo che possa essere mappato su PUT. Significa che la stessa operazione PUT/UPDATE può essere applicata più volte ma solo prima cambierà lo stato del nostro sistema/database.
Pertanto, l'utilizzo di PUT per INSERT annullerà il requisito della semantica HTTP che l'operazione PUT deve essere idempotente.
Non completamente vero. Se guardi la risposta di Cristian Boariu.Quando si usa PUT per inserire mentre il client fornisce l'ID, il secondo PUT con lo stesso ID sovrascrive la risorsa appena creata invece di crearne una nuova. Ciò manterrebbe l'operazione idempotente. –
Qui http://www.w3.org/Protocols/rfc2616/rfc2616.html è la guida ufficiale di come implementare il comportamento dei metodi HTTP.
Seroiusly? La tua risposta è "leggi l'intero RFC HTTP"? Non parla di REST o delle convenzioni standard utilizzate oggi per l'implementazione dei servizi RESTful. Ho scritto il server web su cui sto lavorando, quindi so come funziona HTTP. Sto cercando di utilizzare le best practice quando si implementa un servizio REST in esecuzione su quel server. – ctacke
No, per capire come funzionano i metodi HTTP è sufficiente leggere le parti sui metodi HTTP :-P. Uno dei vincoli REST, Uniform Interface, implica fondamentalmente che quando si esegue REST su HTTP, RFC2616 è la tua bibbia. Forse quello che stai cercando è il Cookboy REST che è un insieme di ricette standard per risolvere problemi comuni nei sistemi RESTful.http: //www.amazon.com/RESTful-Web-Services-Cookbook-Scalability/dp/0596801688/ ref = sr_1_1? ie = UTF8 & s = books & qid = 1268695534 & sr = 8-1 –
I verbi sono:
GET {path}: Recuperare la risorsa il cui identificatore è {path}.
PUT {path}: Creare o aggiornare la risorsa il cui identificativo è {path}.
DELETE {path}: Elimina la risorsa il cui identificatore è {path}.
POST {path}: Invoke un'azione identificata da {path}.
Quando l'intenzione è quella di creare una nuova risorsa, possiamo usare PUT se sappiamo che cosa l'identificatore della risorsa dovrebbe essere, e possiamo usare POST se vogliamo che il server per determinare l'identificativo della nuova risorsa.
La tua definizione di POST contraddice entrambi i documenti a cui mi sono collegato. Sembra anche indicare l'uso di un verbo che, credo, sia scoraggiato – ctacke
Hai ragione. La mia definizione contraddice sia le definizioni di IBM che Sun, perché sia IBM che Sun hanno sbagliato. Si prega di consultare la tabella degli esempi e dei significati su http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services – yfeldblum
Si noti che 'GET',' PUT' e 'DELETE' sono standard hashtable (oggetto JavaScript, hash di Ruby, Python dict) operazioni. Su hashtables, questi metodi sono tutti idempotenti. Al contrario, 'POST' richiama l'immagine di invocare un metodo complesso su un servizio, piuttosto che eseguire una semplice operazione su una tabella hash. Infatti, 'POST' è destinato a tutti i casi d'uso in cui le tre semplici operazioni di hashtable (' GET', 'PUT' e' DELETE') sono insufficienti. – yfeldblum
Ultimamente ho studiato i concetti e le implementazioni di REST e il consenso generale sembra essere: PUT viene utilizzato per la creazione/aggiornamento a seconda che la risorsa esista già o meno. Il POST viene utilizzato per aggiungere una risorsa a una raccolta.
Vedi HTTP/1.1 Metodo Definizioni http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
POST è progettato per consentire un metodo uniforme per coprire le seguenti funzioni:
- Annotation of existing resources; - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles; - Providing a block of data, such as the result of submitting a form, to a data-handling process; - Extending a database through an append operation.Le richieste metodo PUT che l'entità racchiuso essere immagazzinato sotto il fornito Request-URI. Se l'URI di richiesta fa riferimento a una risorsa già esistente, l'entità inclusa DOVREBBE essere considerata come una versione modificata di di quella che risiede sul server di origine.
vedere anche la risposta accettata alla domanda a Understanding REST: Verbs, error codes, and authentication.
rendere questo un wiki comunità, per favore, dal momento che "generalmente accettato" è difficile da definire. –