ID univoci per risorse nidificate

Question

ID univoci per risorse nidificate

#1 da (2 voti)

1

Ho un paio di risorse annidate come Merchant , Hotel , Room . Un commerciante può avere molti hotel e allo stesso modo un hotel può avere molte stanze. In questo momento per gestire queste risorse faccio qualcosa del tipo:

Crea

POST api/v1/merchants/11/hotels

crea un nuovo hotel.

Aggiorna

PUT api/v1/merchants/11/hotels/42

aggiorna l'hotel specificato.

Lo stesso per leggere ed eliminare.

Per le stanze:

Crea

POST api/v1/merchants/11/hotels/42/rooms

crea una nuova stanza.

Aggiorna

PUT api/v1/merchants/11/hotels/42/rooms/42

aggiorna la stanza indicata ecc.

In futuro ci saranno più risorse annidate come le strutture della stanza ecc. e seguendo questo schema diventerà peloso.

Sono nella fase iniziale dello sviluppo e potrei esporre queste API per gli sviluppatori, quindi non posso modificare molto rapidamente lo schema API.

Sono in dubbio dal primo giorno per quanto riguarda questo approccio. Posso supporre che ogni entità abbia un ID univoco (che è vero per ora visto che sto usando un database relazionale e ho una sua tabella)? Se sì, allora posso usare questi URL per le API invece di quelle precedenti?

POST api/v1/rooms

PUT api/v1/rooms/42

Etc per più risorse annidate.

C'è qualche violazione della semantica o dello standard che potrebbe mancare? Sto usando un approccio simile nelle opinioni, ad es. in URL nei browser che sembra troppo brutto.

domain-driven-design architecture web-development rest

posta CodeYogi 16.07.2017 - 06:27

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design architecture web-development rest

Le proprietà dei componenti di nidificazione sono mantenibili a lungo termine? Devo dividere i miei messaggi con i canali o con i contenuti?

score 2 · Accepted Answer

following this scheme will turn hairy

Puoi spiegare perché pensi che il design annidato sia sbagliato?

Can I assume that each entity has unique ID? If yes, then the can I use these URLs for APIs instead of above ones?
POST api/v1/rooms
PUT api/v1/rooms/42

Tipicamente ogni tipo di entità avrà il suo spazio id, e ogni istanza avrà un id da quello spazio. Ogni stanza avrà un ID diverso da ogni altra stanza. Non avere in questo modo, ma di solito lo è, e sì che ti darebbe flessibilità e ti permetterebbe di adottare una struttura piatta come suggerisci.

Originariamente pensavo che forse una struttura piatta sarebbe stata migliore. Ti permetterebbe di gestire un hotel o una stanza senza dover conoscere le entità genitore, ma dopo aver pensato un po 'al problema, è logico che tu abbia bisogno di conoscere il commerciante e l'hotel prima di cambiare stanza. Ho ragione nel pensare che un hotel appartenga solo a un singolo commerciante e una stanza appartenga solo a un determinato hotel? Se si tratta di relazioni uno a uno, la struttura nidificata rende molto di buon senso.

La scelta che fai sarà in definitiva decisa dai tuoi casi d'uso. In che modo gli sviluppatori accederanno alla tua API? Stanno andando a guardare solo un mercante? - In tal caso, potresti voler non mostrare loro il livello merchant (ricerca merchant da autenticazione). Stanno andando ad iterare su ogni camera o hotel dell'API indipendentemente dal venditore? - Se è così, la struttura piatta ha molto senso. Rispondere a queste domande ti aiuterà a decidere come strutturare la tua API e potresti decidere di entrambi una struttura piatta e una struttura nidificata per soddisfare tutti i tuoi casi d'uso.