Qual è un modo corretto di fare un complesso metodo di ricerca RESTful?

Prima di leggere la mia risposta, vorrei dire che sono d'accordo con @Neil. Dobbiamo scegliere le nostre battaglie. Di solito vogliamo fare del nostro meglio, ma a volte c'è troppo poco spazio per la discussione e dobbiamo prendere decisioni contro la nostra volontà.

Comunque, nella risposta di Neil, mi manca ancora una cosa. Documentazione . Solo per assicurarti che gli sviluppatori sappiano che le richieste POST a /search sono sicure.

Detto questo.

1. Dai la possibilità di ottenere

Considera prima l'opzione GET . Dai un'occhiata a questa domanda la lunghezza massima dell'URL . Valutare se la stringa di query più lunga è più lunga di 2000 caratteri. Se non lo fa, e non ti aspetti che sia, vai con GET . Potrebbe sembrare brutto, ma almeno puoi aggiungere l'URL ai segnalibri e, naturalmente, ha tutti i vantaggi derivati dalla semantica del metodo (idempotence, safe e caching)

1.1 Prova a codificare la stringa di query

Ad esempio, nella base 64. Anche javascript supporta le codifiche di base 64 .

Ecco come funziona:

1. Costruisci il JSON con tutti i filtri e normalizzalo.
2. Analizzalo su stringa
3. Codifica
4. Invia il JSON codificato come parametro della richiesta ( /search?q=SGVsbG8gV29ybGQh.... ).
5. Sul lato server, decodifica il parametro q .
6. Deserializza la stringa JSON

In precedenza, crea la stringa JSON più lunga possibile, codificale e prendi la lunghezza. Valutare se la stringa codificata si adatta all'URL. Ho implementato il seguente snippet su Fiddle.js per il test. (Spero funzioni ancora) ¹

Le codifiche Base 64 sono deterministiche e reversibili, quindi non c'è possibilità di collisioni.

Con le query codificate, potremmo anche salvare le ricerche nel DB, aggiungere un segnalibro all'URL, condividere link, ecc. E, naturalmente, non dobbiamo sfuggire / rimuovere la stringa.

1.2 Prova con alias

Leggendo questo blog su come progettare le API REST, ne ho ricordato uno più alternativa. Alias per query comuni .

Trovo che questi siano interessanti per alcuni motivi:

• Riduci la lunghezza della stringa della query. Rende le API più pulite e facili da usare

  GET / ticket /? status = chiuso & chiuso; chiuso = xxx vs GET / ticket / chiudi di recente /

• Combinabile con più alias o più parametri di richiesta.

  GET / ticket /? status = chiuso & chiuso; chiuso = xxx & within = 30min vs GET / ticket / chiudi di recente /? Within = 30min

• Potremmo combinare alias con stringhe di query codificate

  GET / ticket /? status = chiuso & chiuso; chiuso = xxx & within = 30min vs GET / ticket / chiudi di recente /? Q = SGVsbG8g ...

^{1: Ho usato JSON, ma potremmo usare altri formati non appena possiamo deserializzare sul lato server.}

Se tutto ciò che hai è un martello, tutto sembra un chiodo. Sembra che il problema qui sia che stai cercando di trasformare una pagina di ricerca in una RESTful, e questo difficilmente sembra essere un modello comune per la progettazione RESTful da risolvere.

Basta andare con una richiesta POST con parametri forniti dall'utente per ottenere le informazioni richieste dal back-end. Presumo che non devi fare altro che eseguire una ricerca, quindi non c'è alcuna possibilità che tu debba inserire attraverso questa pagina. Basta aggiungere una / ricerca alla fine del tuo URL in modo da non rischiare di imbattersi in conflitti con la tua pagina / utenti che sarebbe essere RESTful.

Dipende completamente da quale è il tuo modello di API: come nessuno o come verbo.

Se l'API è una none, potresti voler ottenere l'elenco di oggetti come segue:

GET: /api/v1/objects

In questo caso devi inviare i dati come parametri di richiesta. Quindi devi descrivere i tuoi parametri come un elenco semplice di valori-chiave:

GET: /api/v1/objects

key1 : val1
key2.key1 : val 21
key2.key2 : val 22
....

Alcune piattaforme supportano il parametro resolver personalizzato (ad es. Spring MVC), puoi convertire parametri in un oggetto.