Query complessa per risorsa

1

Supponiamo che offra un'API REST'ish che offre Pasti

Ora, se vuoi ottenere TUTTI i pasti in modo naturale, ottieni qualcosa del tipo:

GET / pasti

se vuoi filtrare quei pasti puoi fare qualcosa come:

GET / pasti? vegetarian = true

Ma cosa faccio per una richiesta molto complessa in cui la "query" è più simile a:

[
    vegetarian=true,
    persons = [
      person1 = [age: 15, allergens: [peanut, shrimp]],
      person2 = [age: 25, allergens: []],
    ]
]

Il mio approccio sarebbe quello di inviare questo via. un JSON-POST ma se segui il paradigma REST questo sarebbe un GET poiché la risorsa sottostante non viene toccata.

Devo stare con il mio approccio al POST che mi sembra un po 'innaturale o dovrei semplicemente mettere tutte le informazioni in una gigantesca stringa GET-Parameter?

    
posta gries 26.08.2016 - 14:41
fonte

2 risposte

2

Sembra che tu abbia una risorsa aggiuntiva, un pasto o qualcosa del genere. Una risorsa in REST non è una tabella di database o qualcosa del genere. Quindi puoi semplicemente restituire i record della tabella dei pasti dal tuo database in un'altra risorsa come un mealAdvice.

Questo ti porterà a questo:

POST /mealsAdvices
...your data example here here...

Restituisce

HTTP/1.1 201 Created
Location: /mealsAdvices/123

Opzionalmente contiene anche i pasti all'istante in modo da non dover visitare l'url:

HTTP/1.1 201 Created
Location: /mealsAdvices/123
...your data example here here... (can be handy to see why that advice was made)
... meals advice here...

Alternativa che potrebbe essere interessante per la tua app: salva tutti i consigli per un utente sotto:

/users/{userId}/mealsAdvices

Quindi puoi anche mostrare un elenco di consigli che avevano prima. Ad esempio potresti anche "gradire" i consigli con un aggiornamento a tale consiglio. Dipende solo da cosa vuoi fare con i consigli più tardi.

    
risposta data 26.08.2016 - 16:01
fonte
2

GET dovrebbe essere preferito se puoi sopportarlo.

Tuttavia, non esiste una regola che dica che la query deve essere una coppia di valori chiave.

GET /meals?%5B%0A%20%20%20%20vegetarian%3Dtrue%2C%0A%20%20%20%20persons%20%3D%20%5B%0A%20%20%20%20%20%20person1%20%3D%20%5Bage%3A%2015%2C%20allergens%3A%20%5Bpeanut%2C%20shrimp%5D%5D%2C%0A%20%20%20%20%20%20person2%20%3D%20%5Bage%3A%2025%2C%20allergens%3A%20%5B%5D%5D%2C%0A%20%20%20%20%5D%0A%5D

Non c'è niente di sbagliato in questo identificatore, a patto che non inizi a scovare limiti artificiali nei tuoi user-agent / gateway.

Potresti anche considerare di esaminare GraphQL . La struttura di una query GraphQL è un po 'come una rappresentazione di oggetti, quindi potrebbero esserci idee utili da sollevare da coloro che sperimentano combinando GraphQL e" REST ".

Potresti anche voler esaminare la proposta di SEARCH e vedere se ogni nuovo progresso è stato fatto.

La polizia REST potrebbe non essere soddisfatta della natura della query RPC-ish; l'utilizzo di un blocco json in forma libera (come l'utilizzo di una query graphQL) assomiglia molto a una serie di informazioni su come creare una query comunicata fuori banda dal server al client. Questo è un no-no se ti aspetti che il client e il server si evolvano indipendentemente l'uno dall'altro. Nella maggior parte dei casi, va bene a livello pratico.

    
risposta data 26.08.2016 - 15:36
fonte

Leggi altre domande sui tag