Quale dovrebbe essere lo standard per gli URL ReSTful?

Question

Poiché non riesco a trovare un lavoro di chuffing, ho letto su ReST e ho creato servizi web. Il modo in cui l'ho interpretato, il futuro è tutto sulla creazione di un servizio web per tutti i tuoi dati prima di costruire l'app web. Quale sembra una buona idea.

Tuttavia, sembra che ci siano molti pensieri contraddittori su quale sia lo schema migliore per gli URL ReSTful.

Alcuni suggeriscono di URL semplici belle

http://api.myapp.com/resource/1 

Inoltre, alcune persone piace aggiungere la versione API per l'url in questo modo

http://api.myapp.com/v1/resource/1

E per rendere le cose ancora più confuse, alcune persone sostengono l'aggiunta del tipo di contenuto per ottenere le richieste

http://api.myapp.com/v1/resource/1.xml 
http://api.myapp.com/v1/resource/1.json 
http://api.myapp.com/v1/resource/1.txt 

Mentre altri pensano che il tipo di contenuto debba essere inviato nell'intestazione HTTP.

Soooooooo .... Questa è una grande variazione, che mi ha lasciato incerto su quale sia il miglior schema di URL. Personalmente vedo i vantaggi dell'URL più completo che include un numero di versione, un localizzatore di risorse e un tipo di contenuto, ma sono nuovo per questo, quindi potrei sbagliarmi.

D'altra parte, si potrebbe obiettare che si dovrebbe fare "qualunque cosa funzioni meglio per te". Ma ciò non si adatta alla mentalità della ReST per quanto posso dire, dal momento che lo scopo è quello di avere uno standard.

E poiché molti di voi avranno più esperienza di me con ReST, ho pensato di chiedere un consiglio. Quindi, con tutto questo in mente ...

Quale dovrebbe essere lo standard per ReSTful URL?

Answer 1

Benvenuti nel mondo confuso di cosa è e cosa non è REST. Per prima cosa suggerirei di leggere REST nei posti sbagliati. Prova RESTWiki come un buon punto di partenza.

REST non è una soluzione eccezionale per la fornitura di servizi di dati per la tua app Web. I "servizi Web" (noti anche come SOAP, XML-RPC, WSDL, HTTP-POX) possono essere utili, ma lo stile architettonico REST è molto più orientato agli scenari client-server che agli scenari server-server.

Smetti di pensare a quale URL assomiglia. Ciò che sembrano ha molto più a che fare con il framework lato server che si utilizza per implementare il servizio RESTful rispetto alla progettazione del servizio stesso. Il client dovrebbe scoprire gli URL dalle rappresentazioni recuperate in precedenza, quindi non gli interessa davvero come sono gli URL.

Detto questo, utilizzando gli URL di esempio per cercare di distinguere ciò che ritieni debba essere risorse diverse, ho altri suggerimenti.

Non risorse di versione. Ad esempio, se si dispone di una risorsa a cui si accede tramite l'url http://example.org/TodaysWeather, non creare mai una risorsa a http://example.org/V2/TodaysWeather. Esistono molti altri modi migliori per le rappresentazioni della versione rispetto alla creazione di una risorsa completamente nuova. Cerca SO per molte altre discussioni su questo.

Come per la creazione di diverse risorse per diversi tipi di contenuto, credo che sia una decisione specifica per il contesto. Se l'utente finale utilizza un browser per accedere al servizio REST e sono abbastanza sofisticati da comprendere la differenza tra JSON e XML, andare avanti e creare due risorse. Se si tratta di un client macchina, utilizzerei la negoziazione del contenuto per ottenere il formato richiesto.

Infine, fate attenzione là fuori, dal momento che REST è diventato una parola d'ordine del giorno, ci sono molti più contenuti informati in modo errato rispetto a contenuti validi.

Answer 2

Il verbo non può essere inserito nell'URL. Non ha senso. È già presente nell'intestazione della richiesta. Quando invii una richiesta POST con GET nell'URL, è pazzesco.

Il formato di risposta di solito viene inserito nell'URL perché le intestazioni non forniscono un luogo semplice e non ambiguo per inserire tali informazioni.

Answer 3

Sono con S.Lott - il verbo * non dovrebbe * essere lì, poiché si desidera utilizzare lo stesso URL per leggere il record come per aggiornarlo affinché si qualifichi come REST.

Il tipo di contenuto è un'altra cosa da escludere, poiché è lo stesso record, ma con più formati di codifica. (Leggi su FRBR per molto più di quanto tu abbia mai voluto sapere sui problemi della distinzione). La decisione su quale versione inviare in risposta può essere gestita con intestazioni HTTP Accept.

L'unico a cui sono sottoposto è il numero di versione, poiché non riesco a pensare personalmente a un'intestazione HTTP appropriata per gestirne l'aspetto. (Aspettatevi? Accept-Encoding? Pragma? Forse anche Upgrade, ma più spesso vorrete effettuare il downgrade a una versione precedente per motivi di compatibilità, penserei) Probabilmente avrò un accessor versionless che ha dato il più recente versione di produzione, ma potrebbe prendere in considerazione una versione per modifiche significative che non erano compatibili con le versioni precedenti.

aggiornamento: il problema della versione dipende probabilmente dalla quantità di controllo che si ha sui client che si connettono ai servizi ...se hai accesso da un vasto pubblico (cosa che non lo faccio), potresti essere più interessato alla retrocompatibilità. A seconda delle modifiche apportate, è possibile che si consideri che la "versione 2" sia una risorsa completamente nuova, piuttosto che una nuova "versione" dell'originale.

Answer 4

Versioning: di solito ho visto questo posto dove ce l'hai nella tua URL di esempio, e se una versione non è specificata devi rispondere con la versione di produzione più recente. Una considerazione è se mettere la versione dell'API nella stringa di risposta per scopi di debug del client.

Formati di risposta: il formato di ritorno deve essere specificato nell'intestazione HTTP Accept inviata dall'agent user.

Verbi nella stringa richiesta: Assolutamente no.