Dovrei RESTify mie chiamate RPC su HTTP?

Question

Abbiamo HTTP webservices che sono RPC. Tornano XML che rappresenta l'oggetto della sia recuperato o creato. Voglio sapere i vantaggi (se del caso) di "restifying" i servizi.

• http://www.example.com/createDoodad
• http://www.example.com/getDoodad?id=13
• http://www.example.com/getWidget?id1=11&id2=45
• http://www.example.com/createWidget
• http://www.example.com/createSprocked

Una cosa che vedo è che non abbiamo bisogno di rappresentazioni per ogni risorsa e non abbiamo bisogno per supportare tutte le operazioni (GET, PUT, POST, DELETE) su tutte le risorse sia. Fondamentalmente la mia domanda è questa.

convincermi che dovrei usare servizi riposanti, invece di RPC su HTTP e che cosa avrei tali servizi riposanti dovrei essere?

Answer 1

Per prima è tutta una questione semantica, un URI è un Uniform Resource Indicatore. HTTP fornisce metodi per GET, POST, PUT e DELETE una risorsa. intestazioni HTTP specificano in quale formato voglio ricevere o inviare le informazioni. Tutto questo è prontamente disponibile attraverso il protocollo HTTP.

Così si potrebbe riutilizzare lo stesso URL si utilizza per l'output HTML per ottenere XML, JSON in un modo che HTTP è stato pensato per essere utilizzato.

XML-RPC e SOAP sono basati su chiamare i metodi che sono descritti da un file XSD o WSDL mentre REST si basa su come ottenere / modifica risorse. La differenza è sottile ma evidente. L'URL descrive solo la risorsa e non l'azione come è spesso il caso con SOAP e XML-RPC.

I benefici del resto sono che si può utilizzare verbi HTTP per modificare una risorsa come supposto a una chiamata di metodo che potrebbe essere nominato creare / new / aggiungere, ecc codici di stato HTTP significativi invece di diversi tipi di risposte di errore e di essere in grado per specificare diversi formati sulla stessa risorsa in un modo standard.

Inoltre, non c'è bisogno di accettare tutti i verbi su una risorsa RESTful, per esempio se si desidera una risorsa di sola lettura solo restituire un codice di stato 405 Method Not Allowed su qualsiasi verbo che non è GET.

In caso di rifare chiama il tuo RPC per riposare? No, io non la penso così. I benefici non superano i tempi di sviluppo. In caso di imparare resto Quando si imposta un nuovo servizio Web? Sì, io personalmente lo credo, consumando una risorsa REST si sentirà molto più naturale e può crescere molto più rapidamente.

Modifica

Perché mi sento RESTO conquista XML-RPC / SOAP è che quando lo sviluppo di siti web già aggregare tutti i dati neccessary per l'output HTML, inoltre scrivete convalidare il codice per i corpi POST. Perché si dovrebbe passare a un protocollo diverso solo perché il cambiamento di trasporto di marcatura?

In questo modo quando si progetta un nuovo sito web (lingua agnostico) se si pensa veramente di URI di come risorse che, fondamentalmente, di utilizzare le URI di come le chiamate di metodo con il verbo HTTP anteponendo la chiamata al metodo.

Cioè, un GET sulla / prodotti / 12 con un'intestazione HTTP Accept: application/json; fondamentalmente (immaginari) traduce getProducts(12,MimeType.Json).

Questo 'metodo' ha poi per fare un paio di cose

1. Verificare se sosteniamo JSON come un tipo MIME. (Richiesta di convalida)
2. i dati di richiesta Convalida
3. I dati aggregati per il prodotto 12.
4. Formato per JSON e ritorno.

Se per qualche motivo nei prossimi 4 anni YAML sta per essere il prossimo grande follia e uno di i vostri consumatori desidera parlare con te in quel modo questo tipo MIME è inserito molto più facile che con i servizi web regolari.

Ora prodotto 12 è una risorsa molto probabilmente vuole anche accettare tipi MIME HTML alla visualizzazione detto prodotto, ma per un URI come /product/12/reviews/14/ non hai bisogno di una controparte HTML, si vuole solo i vostri consumatori siano in grado nella quale inserire l'URL che per aggiornare (PUT) / cancellazione (DELETE) la tua opinione.

Nel pensiero di URI rigorosamente come le risorse, non solo un luogo di una pagina web, e queste risorse a loro volta combinata con la richiesta HTTP per chiamate di metodi sul lato server porta a pulire gli URL (SEO friendly) e (cosa più importante? ) facilità di sviluppo.

Sono sicuro che ci sono quadri in qualsiasi lingua che farà automaticamente la mappatura di URI per chiamate di metodi per voi. Non posso raccomandare uno visto che di solito rotolo il mio proprio.

ASP.NET MVC funziona anche sullo stesso principio, ma a mio parere non produce URI RESTful. ASP.NET MVC fa parte verbo della URI di default dopo aver detto che è bene notare che in nessun modo non ASP.NET MVC forza questo (o qualsiasi cosa per quella materia) su di voi.

Se avete intenzione di scegliere un quadro per lo meno dovrebbero:

1. bind di URI a methODS sul server
2. Supporto oggetto di JSON / XML, ecc serializzazione. E 'un dolore se dovete scrivere da soli, anche se, a seconda della lingua, non necessario fin troppo difficile.
3. Esporre una sorta di tipo aiutanti richiesta sicuri per aiutare a determinare ciò che è stato richiesto, senza l'analisi delle intestazioni HTTP manualmente.

Answer 2

Prova a prendere i verbi di URL:

• http://www.example.com/Doodad
• http://www.example.com/Doodad/13
• http://www.example.com/Widget/11/45
• http://www.example.com/Widget
• http://www.example.com/Sprocked

Answer 3

Le stringhe di query non devono essere utilizzati per l'accesso a una risorsa in un gerarchica, modo non-query. stringhe di query sono di solito ignorati quando la cache, che è pericoloso e lento.