La rappresentazione (html, xml, json) restituita da un servizio Web RESTful deve essere determinata dall'URL o dall'intestazione Accept HTTP?Content-Type REST: dovrebbe essere basato sull'estensione o sull'intestazione Accept?
Entrambi sono validi. Citazione di xml.com:
Una risorsa può avere più di un rappresentazione. Ci sono quattro modi di uso frequente della consegna della rappresentazione corretto delle risorse per consumatori:
- negoziazione server-driven. Il fornitore di servizi determina la corretta rappresentazione di dai suoi clienti o utilizza le informazioni fornite nelle intestazioni HTTP come Accept, Accept-Charset, Accept-Encoding, Accept-Language e User-Agent. Lo svantaggio di questo approccio è che il server potrebbe non avere la migliore conoscenza su ciò che un cliente vuole davvero.
- Negoziazione guidata dal cliente. Un client avvia una richiesta a un server . Il server restituisce un elenco di disponibile di rappresentazioni. Il client quindi seleziona la rappresentazione che desidera e invia una seconda richiesta al server . Lo svantaggio è che un client deve inviare due richieste.
- Negoziazione guidata da proxy. Un client avvia una richiesta a un server tramite un proxy. Il proxy passa la richiesta al server e ottiene un elenco di rappresentazioni . Il proxy seleziona una rappresentazione in base a per le preferenze impostate dal client e restituisce la rappresentazione al client .
- Rappresentazione specificata dall'URI. Un client specifica la rappresentazione che vuole nella stringa di query URI .
Dal momento che molti URL RESTful non hanno un'estensione, si dovrebbe/deve basare su Content-Type
edit: non voglio dire questo per suonare duro come lo fa, più di dovrete prestare attenzione al tipo di contenuto e non sarà sempre in grado di fare riferimento all'estensione
Il concetto di "URL RESTful" non esiste o è fuorviante. – aehlke
Questa è una sciocchezza totale. Dimmi che http://foo.com/getuser.php?id=99 è RESTful. Se non lo è, esiste un insieme di URL RESTful e, per definizione, deve essere anche un set RESTful. E questo è un esempio banale, ci sono un sacco di URL e design di siti che possono e non possono essere detti mappare su un sistema RESTful. – annakata
Cosa? Aiuta se gli URI sono leggibili, ed è bene seguire le convenzioni HTTP per la denominazione URI, ma è un problema ortogonale a REST. REST non si cura di quello che sembra. Il server gestisce il proprio spazio URI come preferisce, dal momento che il client non deve sapere nulla su come sono costruiti gli URI, ma semplicemente li riceve attraverso l'ipertesto. Quindi, anche se l'URI di esempio non è molto bello, non ha nulla a che fare con RESTful o no. – aehlke
Utilizzare l'intestazione Accept se fornita, URI come failover.
Puoi fornire un link per provare questa priorità? –
Questa è una non-domanda.
L'accettazione dipende dalla conneg (negoziazione del contenuto). Conneg lascerà decidere al cliente quale tipo di media accettano tramite l'intestazione Accept :. La risposta sarà quindi in quel formato, insieme a Vary: Accept intestazione.
D'altra parte, è anche possibile e perfettamente valido esporre la risorsa come /resource.json e /resource.xml.
L'ideale è quello di implementare sia: /risorsa (URI generico che supporta CONNEG) /resource.xml /risorsa.json
la versione connessa restituita da/resource può semplicemente reindirizzare all'ur uri corretto in base al tipo di supporto negoziato. In alternativa, è possibile restituire la rappresentazione corretta dal uri generico e utilizzare Content-Location per specificare la rappresentazione sepcifica restituita.
Sbagliato, secondo REST. Ogni RESOURCE dovrebbe avere un solo URI - non ogni rappresentazione di quella risorsa. – aehlke
Sembra che tu abbia una visione molto specifica e biamata della nozione di risorsa. Qualsiasi cosa che sia abbastanza utile per essere indirizzabile individualmente può essere assegnato un URI. Se è necessario fare la distinzione tra due formati, è possibile "promuoverli" come risorse. Vedere la nota del W3C sugli URI generici e i commenti di Roy su quale sia la negoziazione del tipo di contenuto da utilizzare per: quando e solo quando la distinzione tra i due tipi di media non è significativa. – SerialSeb
@Wahnfrieden Puoi indicarci la fonte ufficiale per la vostra posizione su questo? Ho visto molte discussioni in merito, ma non ho mai visto alcuna decisione concreta. –
Dato che si parla di un servizio Web RESTful e non di alcun servizio Web, vorrei andare fortemente per ciò che è supportato dallo standard sottostante - HTTP 1.1 e la sua negoziazione del contenuto che si basa sull'intestazione HTTP Accept HTTP.
Come ho spiegato nella risposta a Can I change the headers of the HTTP request send by the browser, l'indirizzo (URI) e la rappresentazione sono due pilastri distinti di un progetto RESTful e non è necessario che vengano mescolati. Non si dovrebbe abusare dell'URI per incorporare rappresentazioni accettabili quando c'è l'intestazione Accept.
Solo se la propria applicazione Web è potenzialmente eseguita e utilizzata in un ambiente in cui è presente un filtro di intestazione HTTP coinvolto da nodi intermedi, è necessario supportare la negoziazione del contenuto basata su URI. A dire il vero, i proxy così invadenti o che funzionano male dovrebbero essere sostituiti se possibile e fattibile.
Cheers!
Shonzilla
Non ci sono problemi con l'utilizzo del tipo di contenuto ... Ne ho parlato sul mio blog http://shouldersofgiants.co.uk/Blog e infine optato per inclusa la rappresentanza nel URI come suggerito in servizi Web RESTful da Richardson e Ruby
+1 il libro di Richardson e Ruby. – opyate
Vedi Chapter 5 - Representational State Transfer (REST) , sezione 5.2.1.2 Rappresentanze di Roy Fielding di dissertation su stili architettonici:
Il formato dei dati di una rappresentazione è conosciuto come un tipo di supporto [48].
Guardando il collegamento, vediamo che si riferisce al MIME. Quindi presumo che in linguaggio giapponese, è rappresentato con un'intestazione Content-Type per POST/PUT e Accept intestazione per GET.
Ecco il resto del paragrafo (per completezza):
Una rappresentazione può essere incluso in un messaggio ed elaborati dal beneficiario in base ai dati di controllo del messaggio e la natura del tipo di supporto. Alcuni tipi di media sono destinati all'elaborazione automatizzata di , alcuni sono destinati al rendering per la visualizzazione da parte di un utente, e alcuni sono in grado di entrambi. I tipi di supporto composito possono essere utilizzati per racchiudere più rappresentazioni in un singolo messaggio.
P.S .: Io non sono sicuro perché le persone non guardano nel luogo dove resto è in realtà definito ...
riguarda le sue PS: quella tesi può essere il luogo in cui è stato originariamente * * definito REST, ma dato che non è uno standard, che non lo rende l'autorità finale sul concetto come mettere in pratica.Alcune domande, come questa, potrebbero non avere una risposta chiara in quel testo, o gli autori successivi potrebbero fare argomenti validi per differire dalle sue linee guida. – IMSoP
Il problema dell'intestazione 'Accept' nella richiesta HTTP è che si tratta di una lista; dando al server una pletora di tipi di media tra cui scegliere (quale scegliere?). Inoltre la funzione 'Accept' è [non affidabile in alcuni browser molto diffusi] (http://www.gethifi.com/blog/browser-rest-http-accept-headers) – Jarl
Quale dovrebbe essere il comportamento se sono specificati entrambi (accettare, e in URL). Spetta allo sviluppatore o forse c'è una convention? –
@ThomasJaskula - Se sono specificati sia Accept sia URL, andare con a.) Il più comune b.) Un valore ragionevole o intelligente predefinito (ad esempio se si può dire al client un browser b/c di un UserAgent, quindi invia qualcosa che un browser può facilmente gestire) – cdeszaq
Non è una risposta corretta, nonostante il ragazzo casuale su xml.com che dice di sì.Modificando l'URL, stai suggerendo che la risorsa sottostante potrebbe essere diversa, anche se sai in anticipo che la risorsa sottostante è sempre la stessa. –