come gestire la raccolta di diversi tipi di risorse

0

Mi chiedevo quali fossero le migliori pratiche in termini di raccolta di ID di risorse di tipi diversi.

Il mio software ha un servizio per ogni risorsa, ciascuna di questa risorsa ha un ID univoco (esadecimale come 3dbea72 ) del loro tipo.

  • pomodoro
  • di patate
  • carota

Voglio creare un nuovo servizio per gestire un paniere di tali risorse.

La soluzione ovvia sarebbe quella di inviare un ID lungo il tipo

getTomatos() -> [{id: "3dea72", ...}, {id: "3dea73", ...}, ...]
getCarrots() -> [{id: "aaaaa2", ...}, {id: "aaaaa3", ...}, ...]
submitBasket([{type: "tomato", id: "3dbea72"}, {type: "carrot", id: "aaaaa2"}])

Ma non sono particolarmente fan di questa soluzione, quindi stavo pensando a qualcosa di più ottimizzato, forse.

Genera un ID auto-descrittivo unico restituito al client dove il primo byte descrive il tipo ei byte successivi l'ID.

<type><id>
013dea72 of the tomato id 3dea72
02aaaaa2 of the carrot id aaaaa2

Per il client, l'interfaccia

getTomatos() -> [{id: "013dea72", ...}, {id: "013dea73", ...}, ...]
getCarrots() -> [{id: "02aaaaa2", ...}, {id: "02aaaaa3", ...}, ...]
submitBasket(["013dbea72", "02aaaaa2"])

La domanda è più sulle migliori pratiche per questo caso, se c'è qualche altra soluzione per risolvere questo problema, quali sono i contro e pron delle due soluzioni.

Grazie.

    
posta Greg Jeanmart 17.08.2018 - 14:52
fonte

1 risposta

1

La tua prima soluzione è in realtà la soluzione ideale per diversi motivi.

  1. Incapsula correttamente un'astrazione. Questa è una buona progettazione dell'API sia che si stia creando un servizio Web o una libreria di classi.

  2. La deduzione di tipi da ID non è ovvia dal punto di vista di un osservatore umano. Aumenta lo sforzo mentale necessario per capire qualcosa che è già astratto.

  3. Il passaggio di un parametro "tipo" esplicito consente al codice lato server di modificare il comportamento in base a questo valore e può essere combinato con il modello di fabbrica per facilitare il polimorfismo nei linguaggi orientati agli oggetti.

Esistono casi d'uso validi per la composizione di un ID in questo modo, ma sono generalmente guidati da politiche aziendali, norme di pubblico dominio o leggi molto vecchie e ben note (come i numeri di targa negli Stati Uniti).

    
risposta data 17.08.2018 - 15:44
fonte

Leggi altre domande sui tag