Modo RESTful per definire un'API che richiede due chiavi per restituire una risorsa

0

Nella mia applicazione, ho una risorsa A che è super class e A1 , A2 che eredita A e altre proprietà che sono specifiche per loro. A non può esistere da solo, deve essere A1 o A2. Questo è un classico esempio di schema gerarchico. Voglio progettare un'API che restituirà la risorsa A con le sue proprietà di sottoclasse. La nostra applicazione è attualmente progettata come due tabelle di database separate A1 e A2 e le loro chiavi primarie sono numeri di sequenza di incremento automatico. Quindi, se devo recuperare una risorsa di type 1, il percorso dell'API deve essere /A/{A1-id}?type=1 . Non mi piace passare type come parametro di query perché è la parte di una chiave che identifica la risorsa e non è un filtro. Sulla base del type , l'applicazione saprà se deve interrogare la tabella A1 o A2 per restituire i dati.

  • Non voglio avere numeri di sequenza che iniziano con numeri diversi per entrambe le tabelle.
  • Ho preso in considerazione la traduzione di proprietà comuni nella tabella A con ID singolo per entrambi i tipi. A1 e A2 diventeranno solo tabelle di associazione. Ma questo cambierà molto codice.
  • Considerato anche la conversione dell'ID della sequenza in entrambe le tabelle in UUID e l'applicazione interrogherà sempre A1 e A2 ogni volta che riceve una richiesta, ma sembra che il livello sia ancora richiesto quando l'aggiornamento è completato o dovrebbe trovare il prima la tabella e poi aggiorna la tabella in query separate invece di aggiornare direttamente la tabella.

Qual è il modo migliore per risolvere questo? Possiamo avere /A/{id}/{typeid} per evitare di apportare molte modifiche al codice? So che non siamo puri RESTful perché questa API è per Angular MVC e non sarà esposta a utenti esterni.

    
posta TechCrunch 10.08.2016 - 23:11
fonte

1 risposta

2

In my application, I have resource A that is super class and A1, A2 that inherits A and other properties that are specific to them. A cannot exist by itself, it must be either A1 or A2

Data questa restrizione, l'implementazione più logica sarebbe avere 2 percorsi API:

  • /A1/{A1-id}
  • /A2/{A2-id}

Poiché il chiamante deve sapere se ottiene un oggetto A1 o A2 e il tipo di oggetto a cui fa riferimento l'ID, non c'è davvero un punto nell'accesso a entrambe le risorse A1 e A2 attraverso lo stesso percorso API.

Potresti considerare di aggiungere un percorso API di sola lettura /A/ per ottenere una combinazione di oggetti A1 e A2 in base a determinati criteri di ricerca.

    
risposta data 11.08.2016 - 09:22
fonte