Non voglio vedere una stringa di parametri così lunga nell'URI. Quindi, il metodo GET può utilizzare i dati JSON?Per l'API Restful, il metodo GET può utilizzare i dati JSON?
Nella mia situazione, ho bisogno di filtrare il tipo di parametri dato risultato. Se ci sono molti parametri, la lunghezza può superare il limite dell'URI. Quindi, c'è la migliore pratica per questo problema?
Per rispondere alla domanda, sì, è possibile passare JSON nell'URI come parte di una richiesta GET (a condizione che si codifichi tramite URL). Tuttavia, considerando che il motivo per cui lo fai è dovuto alla lunghezza dell'URI, l'uso di JSON sarà controproducente (introducendo più caratteri del necessario).
vi consiglio di inviare i parametri nel corpo di una richiesta POST, sia in stile normale CGI (param1=val1¶m2=val2) o JSON (analizzato dalla vostra API al ricevimento)
Tale richiesta è RPC su HTTP. Non è riposante. –
@Tichodroma Ci dispiace, ma è semplicemente sbagliato. Se sta indirizzando la chiamata a una risorsa identificata da un URI, con un metodo definito dal protocollo HTTP, con semantica POST definita dalla risorsa di destinazione, non è RPC. Potrebbe anche non essere REST, ma non è RPC. Sarebbe RPC se il payload JSON contenesse l'identificatore - anziché l'URI - e il metodo da usare - invece di basarsi sulla semantica del metodo HTTP. –
In teoria, non c'è nulla impedisce di invio di una richiesta corpo in una richiesta GET. Il protocollo HTTP lo consente, ma non ha una semantica definita, quindi spetta a te documentare cosa esattamente succederà quando un client invia un payload GET. Ad esempio, è necessario definire se i parametri in un corpo JSON sono equivalenti ai parametri Querystring o qualcos'altro interamente.
Tuttavia, poiché non esiste una semantica chiaramente definita, non si ha alcuna garanzia che le implementazioni tra la propria applicazione e il cliente la rispetteranno. Un server o un proxy potrebbe rifiutare l'intera richiesta o ignorare il corpo o qualsiasi altra cosa. Il modo REST per gestire implementazioni errate è aggirarlo in un modo che è disaccoppiato dalla tua applicazione, quindi direi che hai due opzioni che possono essere considerate best practice.
L'opzione semplice è utilizzare POST anziché GET come consigliato da altre risposte. Dal momento che POST non è standardizzato da HTTP, dovrai documentare esattamente come dovrebbe funzionare. Questa è l'opzione meno valida, ma va bene.
L'opzione RESTful, che preferisco, è quella di implementare l'applicazione supponendo che il carico utile GET non venga mai manomesso. Quindi, nel caso in cui qualcosa abbia un'implementazione rotta, si consente ai client di sovrascrivere il metodo HTTP con lo X-HTTP-Method-Override, che è una convenzione popolare per i client per emulare i metodi HTTP con POST. Quindi, se un client ha un'implementazione interrotta, può scrivere la richiesta GET come POST, inviando il metodo X-HTTP-Method-Override: GET e si può avere un middleware che è disaccoppiato dall'implementazione dell'applicazione e riscrive il metodo di conseguenza. Questa è l'opzione migliore se sei un purista.
Cosa ne pensi di http://stackoverflow.com/a/983458/1907906? –
@Tichodroma Fielding sta dicendo la stessa identica cosa. Un corpo GET non ha alcuna semantica parse definita dal protocollo HTTP, ma ciò non significa che non possa essere utile in un'API REST utilizzando HTTP come protocollo di trasporto.Significa solo che è irrilevante per il protocollo di trasporto stesso e potrebbe non essere rispettato da alcune implementazioni. –
Questa domanda viene posta su SO almeno una volta alla settimana. Sempre le stesse due opposizioni sono proposte come risposta: 1) sì, 'GET' con un corpo di richiesta è RESTful, 2) no, non lo è. Tutti noi non impariamo nulla di nuovo scrivendo le nostre opinioni più e più volte. Per ora, voto per chiudere questa domanda perché è un duplicato. Dovrebbe anche essere chiuso perché le risposte sono principalmente basate sull'opinione pubblica. –