Come progettare percorsi per risorse generalizzate / specializzate

Il punto di un'interfaccia è quello di nascondere il fatto che ci sono diverse implementazioni possibili. Quando ti siedi in un ristorante, in fondo ti interessa solo che riceverai il servizio da qualcuno . Potresti non sapere che potresti ottenere un servizio da Jose, Marcia o Stephanie, e sicuramente non vuoi dover fare cose diverse per ottenere lo stesso cheeseburger da diversi camerieri . La tua visione della transazione come consumatore è "prendi un cheeseburger", non "parla con Jose" / "parla con Marcia" / "parla con Stephanie".

Se il consumatore deve conoscere tutte le possibili implementazioni e a quale vuole accedere, allora per gli scopi della tua API potresti anche non avere un'interfaccia, dal momento che in realtà non stai risparmiando lo sforzo che è dovrebbe salvare Può comunque essere utile per semplificare i dettagli dell'implementazione, ma finché la differenza tra le classi di oggetti alternative è visibile esternamente, l'interfaccia cessa di essere un utile componente API.

Presumo tutti i frutti, le mele, le arance, e così tutti, tutti hanno i frutti. Quindi se vuoi fare riferimento a un frutto specifico in un cestino, allora:

/baskets/{basketId}/fruits/{fruitId)

è ancora valido. Tuttavia, se "fruitId" è unico, sarebbe molto meglio usare solo

/fruits/{fruitId)

Tuttavia, se vuoi vedere solo alcuni tipi di frutta in un cestino, puoi sfruttare la stringa di query nel suo ruolo di "restringimento" della risorsa:

baskets/{basketId}?fruits=mango

o

baskets/{basketId}?fruits=apple&fruits=banana

Una volta ottenuto quell'elenco di elementi, ognuno dovrebbe avere il proprio ID e amp; puoi ottenerli singolarmente se vuoi.

Da un punto di vista RESTful, ci sono due risorse qui:

• una collezione dei frutti in un determinato cestino

• un singolo frutto

Usa la stringa di query per limitare la risorsa raccolta e usa il frutto (più corto) una volta che conosci quale specifico vuoi.

BTW Il problema rimane lo stesso se stai selezionando i frutti dal cappello di qualcuno:

/hat/{hatId}?fruits=bananas&fruits=pineapples

EDIT: (tratto dai commenti quindi sarà più leggibile)

Per aggiungere una mela

POST /basket/{id}

(the apple representation)

POST è spesso considerato il verbo "append", ma potresti usare PUT. Tieni presente che stai aggiungendo la mela alla raccolta del carrello, quindi utilizzi l'URI di raccolta.

Per trovare le mele nel carrello:

GET /basket/{id}?fruits=apple

MODIFICA MODIFICA: se hai in mente qualche altro codice / valore / attributo, supportalo nella stringa della query:

GET /basket/{id}?color=red

Il modo più RESTful sarebbe probabilmente quello di definire percorsi separati per ogni tipo di frutta:

baskets/{basketId}/apples
baskets/{basketId}/apples/{appleId}
baskets/{basketId}/bananas
baskets/{basketId}/bananas/{fruitId}
... other fruits

E usa un tipo di supporto diverso per ogni frutto, ad esempio:

application/vnd.com.example.apple+json
application/vnd.com.example.banana+json

In questo caso è necessario richiedere un elenco di ogni tipo possibile e gestirli singolarmente.

Una soluzione meno RESTful potrebbe essere quella di trattare la frutta come l'interfaccia che sembra così com'è, e solo ottenere un elenco di essi.

baskets/{basketId}/fruits
baskets/{basketId}/fruits/{fruitId}

Dato che JSON di solito è senza schema, ogni elemento può sembrare completamente diverso, e potresti usare alcune caratteristiche identificative per mappare ciascuna alla specifica classe di frutta che comprende la sua rappresentazione JSON e ne contiene il comportamento.