HTTP GET con il corpo della richiesta

Sto sviluppando un nuovo servizio web RESTful per la nostra applicazione.

Quando si esegue un OTTENERE su determinate entità, i clienti possono richiedere il contenuto dell'entità. Se desiderano aggiungere alcuni parametri (ad esempio l'ordinamento di un elenco) possono aggiungere questi parametri nella stringa di query.

In alternativa, desidero che le persone siano in grado di specificare questi parametri nel corpo della richiesta. HTTP / 1.1 non sembra vietarlo esplicitamente. Ciò consentirà loro di specificare più informazioni, potrebbe rendere più semplice specificare richieste XML complesse.

Le mie domande:

• È una buona idea del tutto?
• I client HTTP avranno problemi con l'utilizzo degli organismi di richiesta all'interno di una richiesta GET?

http://tools.ietf.org/html/rfc2616

Il commento di Roy Fielding sull'inclusione di un corpo con una richiesta GET .

Sì. In altre parole, qualsiasi messaggio di richiesta HTTP può contenere un corpo di messaggio e quindi deve analizzare i messaggi tenendo presente questo. La semantica del server per GET, tuttavia, è limitata in modo tale che un corpo, se presente, non ha alcun significato semantico per la richiesta. I requisiti sull'analisi sono separati dai requisiti sulla semantica del metodo.

Quindi, sì, puoi inviare un corpo con GET, e no, non è mai utile farlo.

Questo fa parte del design a strati di HTTP / 1.1 che diventerà di nuovo chiaro una volta che le specifiche saranno partizionate (lavori in corso).

.... Roy

Sì, puoi inviare un corpo di richiesta con GET ma non dovrebbe avere alcun significato. Se gli dai un significato analizzandolo sul server e modificando la tua risposta in base al suo contenuto , stai ignorando questa raccomandazione nelle specifiche HTTP / 1.1, sezione 4.3 :

[...] se il metodo di richiesta non include la semantica definita per un corpo-entità, il corpo del messaggio DOVREBBE essere ignorato quando si gestisce la richiesta.

E la descrizione del metodo GET nelle specifiche HTTP / 1.1, sezione 9.3 :

Il metodo GET significa recuperare qualsiasi informazione ([...]) identificata dall'URI di richiesta.

che afferma che il corpo della richiesta non fa parte dell'identificazione della risorsa in una richiesta GET, ma solo l'URI della richiesta.

Aggiornamento L'RFC2616 indicato come "Specifica HTTP / 1.1" è ora obsoleto. Nel 2014 è stato sostituito dagli RFC 7230-7237. La citazione "il corpo del messaggio DOVREBBE essere ignorato durante la gestione della richiesta" è stata eliminata. Ora è solo "Richiedi l'inquadramento dei messaggi è indipendente dalla semantica del metodo, anche se il metodo non definisce alcun uso per un corpo del messaggio" La seconda citazione "Il metodo GET significa recuperare qualsiasi informazione ... identificata dall'URI di richiesta" è stato cancellato. - Da un commento

Mentre puoi farlo, nella misura in cui non è esplicitamente escluso dalla specifica HTTP, suggerirei di evitarlo semplicemente perché le persone non si aspettano che le cose funzionino in quel modo. Esistono molte fasi in una catena di richieste HTTP e sebbene siano "per lo più" conformi alle specifiche HTTP, l'unica cosa che ti viene assicurata è che si comporteranno come tradizionalmente usato dai browser web. (Sto pensando a cose come proxy trasparenti, acceleratori, toolkit A / V, ecc.)

Questo è lo spirito alla base del principio di robustezza all'incirca "sii liberale in ciò che accetti e conservatore in ciò che invii", non vuoi spingere i confini di una specifica senza una buona ragione.

Tuttavia, se hai una buona ragione, provaci.

Probabilmente incontrerai problemi se proverai a sfruttare la cache. I proxy non guarderanno nel corpo GET per vedere se i parametri hanno un impatto sulla risposta.

Né restclient né console REST supportano questo, ma curl non lo fa.

Le specifiche HTTP sono riportate nella sezione 4.3

Un corpo di messaggio NON DEVE essere incluso in una richiesta se la specifica del metodo di richiesta (sezione 5.1.1) non consente l'invio di un corpo di entità nelle richieste.

La sezione 5.1.1 ci reindirizza alla sezione 9.x per i vari metodi. Nessuno di loro proibisce esplicitamente l'inclusione di un corpo del messaggio. Però...

La sezione 5.2 dice

La risorsa esatta identificata da una richiesta Internet viene determinata esaminando sia il campo dell'intestazione URI richiesta sia quello Host.

e dice la Sezione 9.3

Il metodo GET significa recuperare qualsiasi informazione (sotto forma di entità) identificata dall'URI di richiesta.

Che insieme suggeriscono che quando elabora una richiesta GET, un server non è tenuto ad esaminare altro che il campo dell'intestazione Request-URI e Host.

In breve, le specifiche HTTP non ti impediscono di inviare un corpo di messaggio con GET ma c'è un'ambiguità sufficiente da non sorprendermi se non fosse supportato da tutti i server.

Elasticsearch accetta le richieste GET con un ente. Sembra persino che questo sia il modo preferito: la guida di Elasticsearch

Alcune librerie client (come il driver Ruby) possono registrare il comando cry su stdout in modalità di sviluppo e sta usando questa sintassi ampiamente.

Quello che stai cercando di ottenere è stato fatto a lungo con un metodo molto più comune e uno che non si basa sull'utilizzo di un payload con GET.

Puoi semplicemente costruire il tuo specifico tipo di media di ricerca, o se vuoi essere più RESTful, usare qualcosa come OpenSearch e POST la richiesta all'URI indicato dal server, dì / cerca. Il server può quindi generare il risultato della ricerca o creare l'URI finale e reindirizzare utilizzando un 303.

Questo ha il vantaggio di seguire il tradizionale metodo PRG, aiuta gli intermediari nella cache a memorizzare i risultati, ecc.

Detto questo, gli URI sono comunque codificati per tutto ciò che non è ASCII, così come lo sono application / x-www-form-urlencoded e multipart / form-data. Consiglierei di utilizzare questo invece di creare un altro formato json personalizzato se la tua intenzione è supportare scenari ReSTful.

Puoi inviare un OTTENERE con un corpo o inviare un POST e rinunciare alla religiosità RESTOSA (non è poi così male, 5 anni fa c'era solo un membro di quella fede - i suoi commenti collegati sopra).

Né sono grandi decisioni, ma l'invio di un corpo GET può prevenire problemi per alcuni client e alcuni server.

Fare un POST potrebbe avere degli ostacoli con alcuni framework RESTish.

Julian Reschke ha suggerito sopra usando un'intestazione HTTP non standard come "SEARCH" che potrebbe essere una soluzione elegante, tranne per il fatto che è ancora meno probabile che sia supportata.

Potrebbe essere più produttivo elencare i client che possono e non possono fare ciascuno dei precedenti.

Clienti che non possono inviare un GET con body (di cui sono a conoscenza):

• XmlHTTPRequest Fiddler

Clienti che possono inviare un GET con body:

• la maggior parte dei browser

Server e librerie che possono recuperare un corpo da OTTENERE:

• Apache
• PHP

Server (e proxy) che rimuovono un corpo da GET:

• ?

Ho posto questa domanda al WG HTTP IETF. Il commento di Roy Fielding (autore del documento http / 1.1 nel 1998) è stato quello

"... un'implementazione verrebbe interrotta per fare altro che analizzare e scartare quell'organismo se ricevuto"

RFC 7213 (HTTPbis) afferma:

"Un payload all'interno di un messaggio di richiesta GET non ha una semantica definita;"

Sembra chiaro ora che l'intenzione era che il significato semantico sui corpi di richiesta GET fosse proibito, il che significa che il corpo di richiesta non può essere usato per influenzare il risultato.

Ci sono proxy là fuori che sicuramente interromperanno la tua richiesta in vari modi se includi un body su GET.

Quindi in sintesi, non farlo.

Quale server lo ignorerà? - fijiaaron, 30 agosto 12 alle 21:27

Google, ad esempio, sta facendo peggio che ignorarlo, lo considererà un errore !

Provalo tu stesso con un semplice netcat:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(il contenuto 1234 è seguito da CR-LF, per un totale di 6 byte)

e otterrai:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

Ricevi anche 400 richieste non valide da Bing, Apple, ecc ... che sono servite da AkamaiGhost.

Quindi non consiglierei di usare le richieste GET con un'entità corporea.

Da RFC 2616, sezione 4.3 , "Corpo del messaggio":

Un server DOVREBBE leggere e inoltrare un corpo del messaggio su qualsiasi richiesta; se il metodo di richiesta non include la semantica definita per un corpo di entità, DOVREBBE DOVREBBE essere ignorato durante la gestione della richiesta.

Cioè, i server dovrebbero sempre leggere qualsiasi corpo di richiesta fornito dalla rete (controllare Content-Length o leggere un corpo grosso, ecc.). Inoltre, i proxy dovrebbero inoltrare qualsiasi organo di richiesta che ricevano. Quindi, se RFC definisce la semantica per il corpo per il metodo dato, il server può effettivamente utilizzare il corpo della richiesta per generare una risposta. Tuttavia, se RFC non definisce la semantica per il corpo, il server dovrebbe ignorarlo.

Questo è in linea con la citazione di Fielding sopra.

La sezione 9.3 , "OTTIENI", descrive la semantica del metodo GET e non menziona gli organismi di richiesta. Pertanto, un server dovrebbe ignorare qualsiasi corpo di richiesta che riceve su una richiesta GET.

Secondo XMLHttpRequest, non è valido. Dallo standard :

4.5.6 Il send()metodo

client . send([body = null])

Avvia la richiesta. L'argomento facoltativo fornisce il corpo della richiesta. L'argomento viene ignorato se il metodo di richiesta è GETo HEAD.

Genera InvalidStateErrorun'eccezione se uno degli stati non è aperto o il send()flag è impostato.

Il metodo deve eseguire questi passaggi:send(body)

1. Se lo stato non è aperto , genera InvalidStateErrorun'eccezione.
2. Se la send()bandiera è impostata, lancia InvalidStateErrorun'eccezione.
3. Se il metodo di richiesta è GETo HEAD, imposta body su null.
4. Se body è null, andare al passaggio successivo.

Anche se, non credo che dovrebbe, perché la richiesta GET potrebbe aver bisogno di contenuti di grandi dimensioni.

Quindi, se fai affidamento su XMLHttpRequest di un browser, è probabile che non funzionerà.

Se vuoi davvero inviare un corpo JSON / XML cachhable all'applicazione web, l'unico posto ragionevole per mettere i tuoi dati è la stringa di query codificata con RFC4648: codifica Base 64 con URL e nome file Safe Alphabet . Ovviamente potresti semplicemente urlencode JSON e mettere è nel valore del parametro URL, ma Base64 fornisce risultati più piccoli. Tieni presente che esistono restrizioni sulla dimensione dell'URL, vedi Qual è la lunghezza massima di un URL in browser diversi? .

Potresti pensare che il =carattere di riempimento di Base64 potrebbe essere negativo per il valore param dell'URL, tuttavia non sembra - vedi questa discussione: http://mail.python.org/pipermail/python-bugs-list/2007-February/037195.html . Tuttavia non dovresti mettere dati codificati senza nome param perché la stringa codificata con padding verrà interpretata come chiave param con valore vuoto. Vorrei usare qualcosa di simile ?_b64=<encodeddata>.

Non lo consiglierei, va contro le pratiche standard e non offre molto in cambio. Vuoi mantenere il corpo per il contenuto, non per le opzioni.

Che dire delle intestazioni codificate in base64 non conformi? "SOMETHINGAPP-PARAMS: sdfSD45fdg45 / come"

Limitazioni di lunghezza hm. Non riesci a fare in modo che la tua gestione POST distingua tra i significati? Se vuoi parametri semplici come l'ordinamento, non vedo perché questo sarebbe un problema. Immagino sia una certezza che ti preoccupi.

Sono sconvolto dal fatto che REST come protocollo non supporta OOP e il Getmetodo è una prova. Come soluzione, è possibile serializzare un DTO su JSON e quindi creare una stringa di query. Sul lato server è possibile deserializzare la stringa di query nel DTO.

Dai un'occhiata a:

• Progettazione basata su messaggi in ServiceStack
• Creazione di servizi Web basati su messaggi RESTful con WCF

L'approccio basato sui messaggi può aiutarti a risolvere la restrizione del metodo Get. Sarai in grado di inviare qualsiasi DTO come con il corpo della richiesta

Il framework del servizio Web Nelibur fornisce funzionalità che è possibile utilizzare

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Ad esempio, funziona con Curl, Apache e PHP.

File PHP:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Comando console:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

Produzione:

GET
{"the": "body"}

IMHO potresti semplicemente inviare il JSONcodificato (ad es. encodeURIComponent) In URL, in questo modo non violerai le HTTPspecifiche e arriverai JSONal server.

Hai un elenco di opzioni che sono molto meglio dell'uso di un corpo di richiesta con GET.

Supponiamo che tu abbia categorie ed elementi per ogni categoria. Entrambi devono essere identificati da un id ("catid" / "itemid" per il bene di questo esempio). Si desidera ordinare in base a un altro parametro "sortby" in un "ordine" specifico. Volete passare i parametri per "sortby" e "order":

Puoi:

1. Utilizzare stringhe di query, ad es example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. Usa mod_rewrite (o simile) per i percorsi: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. Usa le singole intestazioni HTTP che hai passato con la richiesta
4. Utilizzare un metodo diverso, ad esempio POST, per recuperare una risorsa.

Tutti hanno i loro lati negativi, ma sono molto meglio che usare un GET con un corpo.

Anche se uno strumento popolare lo utilizza, come spesso citato in questa pagina, penso che sia ancora una pessima idea, essendo troppo esotico, nonostante non sia proibito dalle specifiche.

Molte infrastrutture intermedie possono semplicemente rifiutare tali richieste.

Con l'esempio, dimenticare utilizzando alcuni dei CDN disponibili di fronte al vostro sito web, come questo uno :

Se una GETrichiesta del visualizzatore include un corpo, CloudFront restituisce al visualizzatore un codice di stato HTTP 403 (vietato).

E sì, le librerie client potrebbero anche non supportare l'emissione di tali richieste, come riportato in questo commento .

Sto usando RestTemplate del framework Spring nel mio programma client e, sul lato server, ho definito una richiesta GET con un corpo Json. Il mio scopo principale è lo stesso del tuo: quando la richiesta ha numerosi parametri, inserirli nel corpo sembra più ordinato che inserirli nella stringa URI prolungata. Sì?

Ma, purtroppo, non funziona! Il lato server ha generato la seguente eccezione:

org.springframework.http.converter.HttpMessageNotReadableException: corpo della richiesta richiesto mancante ...

Ma sono abbastanza sicuro che il corpo del messaggio sia correttamente fornito dal mio codice client, quindi cosa c'è che non va?

Ho rintracciato nel metodo RestTemplate.exchange () e ho trovato quanto segue:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

Si noti che nel metodo executeInternal (), l'argomento di input 'bufferedOutput' contiene il corpo del messaggio fornito dal mio codice. L'ho visto attraverso il debugger.

Tuttavia, a causa del preparConnection (), getDoOutput () in executeInternal () restituisce sempre false che, a sua volta, rende bufferedOutput completamente ignorato! Non viene copiato nel flusso di output.

Di conseguenza, il mio programma server non ha ricevuto il corpo del messaggio e ha generato tale eccezione.

Questo è un esempio del RestTemplate del framework Spring. Il punto è che, anche se il corpo del messaggio non è più proibito dalle specifiche HTTP, alcune librerie o framework client o server potrebbero comunque essere conformi alle specifiche precedenti e rifiutare il corpo del messaggio dalla richiesta GET.