Best practice per la chiamata all'API REST con molti parametri

Question

Best practice per la chiamata all'API REST con molti parametri

#1 da (3 voti)
#2 da (1 voti)

4

Ho un'API REST con operazioni GETs che ricevono un (lungo) elenco di parametri (8 parametri, ad esempio). Lo scopo di questa operazione è di cercare e filtrare gli elementi.

Qual è la migliore pratica per gestire questo scenario?:

(1) Ricevi un elenco di parametri?:

public ResultType Get(int p1, int p2, string p3...) { ... }

(2) O ricevi un oggetto che incapsula questi parametri ?:

public class MyClass
{
    public int X { get; set; }
    public int Y { get; set; }
    public string Z { get; set; }
}

public ResultType Get(MyClass parameter) { ... }

Pensa in uno scenario di eCommerce in cui desideri cercare e filtrare "prodotti" per nome, descrizione, categoria, marca, modello, prezzo, ecc ...

rest patterns-and-practices web-api

posta Jose Alonso Monge 31.08.2018 - 09:35

fonte

2 risposte

Leggi altre domande sui tag rest patterns-and-practices web-api

Strutture di dati multiple contenenti gli stessi riferimenti Come utilizzare correttamente un database contenente tabelle comuni in un sistema multi-applicazione?

score 3 · Answer 1

I have a REST API with GETs operations which receive a (long) list of > parameters. Which is the best practice to manage this scenario?

AFAIK, non esiste una best practice ben stabilita (mi dispiace). Tuttavia, è possibile formulare alcune raccomandazioni:

Prova a evita di utilizzare POST (anziché GET ) se la richiesta è sicura (es. privo di effetti collaterali, in particolare non modifica dati). Se i parametri sono molto grandi, potresti dover usare POST per aggirare i limiti di lunghezza, ma solitamente questo non è un problema (la maggior parte dei software supporta URL piuttosto lunghi) e le richieste sicure dovrebbero usare GET per consentire ottimizzazioni come memorizzazione nella cache e prefetch.
Se utilizzi GET , devi inviare i parametri come parametri URL ¹⁾. In tale situazione, la soluzione naturale e comune è quella di utilizzare un elenco di parametri , quindi è quello che consiglierei. Sì, la lista sarà lunga, ma l'API REST è (probabilmente) destinata all'uso programmatico, quindi non vedo un problema con questo. Gli utenti dell'API sono liberi di incapsulare i parametri in un oggetto all'interno del proprio codice.
Tecnicamente, potresti anche inserire un oggetto in un parametro URL (come JSON, XML o qualsiasi altra cosa), ma è insolito, quindi lo eviterei se possibile.

1) In senso stretto, puoi usare un corpo con una richiesta di GET , ma questo è insolito e generalmente non raccomandato; vedere per es. HTTP GET con il corpo della richiesta .

Infine, proprio come con i metodi nel codice sorgente che hanno elenchi di parametri lunghi, potresti voler considerare se l'API REST ha bisogno di un refactoring. Proprio come nel codice sorgente, un elenco di parametri così lungo indica che l'endpoint dell'API sta facendo molte cose diverse. Forse ha senso dividerlo o fornire impostazioni predefinite? Ma questa è una domanda diversa ...

score 1 · Answer 2

La procedura migliore è POSTARE i parametri come oggetto.

Questo evita il limite di lunghezza dell'URL e altri problemi con le stringhe di query. Se invii più parametri in JSON, un oggetto è il modo standard per farlo, quindi deserializzare con uno ha senso.

Puoi evitare di creare oggetti di "Richiesta" casuali che sono usati solo nei tuoi Controllori deserializzando su un oggetto dinamico, se lo desideri; anche se il casting per i tipi giusti in seguito può essere ugualmente disordinato.

Ai vecchi tempi avresti potuto avere più parametri nell'azione del tuo controller vincolati automaticamente ai campi di un oggetto JSON in arrivo. Ma questo non funziona più fuori dalla scatola in .net core.

Anche se c'è questo, che potrei essere tentato di provare

link

Modifica: aggiungo solo alcuni punti sull'uso di GET

Caching: GET verrà memorizzato nella cache da client che rispettano le specifiche HTTP. Ma la specifica è progettata per far caricare più velocemente le pagine web. La memorizzazione nella cache è utile se il risultato dell'API presenta gli stessi requisiti di cache di una pagina Web, ma inutile se non lo è. È possibile aggiungere la propria memorizzazione nella cache delle risposte POST nel client, se necessario.
Lunghezza URL: si tratta principalmente di un problema quando si invia un array. Ovviamente una matrice può facilmente diventare molto lunga e i nomi dei parametri della stringa di query verranno ripetuti per ciascun elemento. Tuttavia, anche se invii solo una stringa, tecnicamente quella stringa può essere molto lunga.
Registrazione: per impostazione predefinita molti server Web registreranno l'intera stringa di query. Spesso non vuoi che i dati dei parametri finiscano nei log di testo normale.
OTTIENI con il corpo: questa sembra essere la risposta perfetta, soddisfacendo i puristi di REST pur consentendo una buona struttura dati, ma è insolito e disapprovato, un POST è il modo standard per inviare un corpo.