RESTful URI map to database tables?

When designing a RESTful API, should your URI map to tables (for the most part).

No, assolutamente no.

URIs do NOT map onto domain objects - that violates encapsulation. Work (ex: issuing commands to the domain model) is a side effect of managing resources. In other words, the resources are part of the anti-corruption layer. You should expect to have many many more resources in your integration domain than you do business objects in your business domain. -- Jim Webber

When designing a RESTful API, should your URI map to tables (for the most part)?

No. In un'API RESTful, gli URI devono essere associati a risorse (logiche).
Può succedere che una risorsa nella tua applicazione corrisponda a (una riga in) una singola tabella, ma questo non è certo il caso quando entrano in gioco relazioni e / o risorse più complesse.

Per il tuo esempio di utenti e disponibilità, ci sono due opzioni comunemente usate (che sono non che si escludono a vicenda. Puoi usarle entrambe allo stesso tempo):

• Rendi le informazioni sulla disponibilità parte della risorsa utente

  GET /users/3
  
  {
    first_name: "Jack",
    last_name: "Daniels",
    email: "c.com",
    role: "Admin",
    availability: [
      { date: "2017-06-19", status: "Available" },
      { date: "2017-06-24", status: "Available" }
    ],
    links: { 
      self: /users/3
    }
  }
  

• Esporre le informazioni sulla disponibilità come sotto-risorsa sotto la risorsa utente

  GET /users/3/availability
  
  [
    { date: "2017-06-19", status: "Available" },
    { date: "2017-06-24", status: "Available" }
  ]
  

L'id che segue una collezione dovrebbe corrispondere a una risorsa unica di quella raccolta. Come uno sviluppatore vedendo

www.example.com/availability/3

sarebbe confuso poiché penserei che questa sia la risorsa di disponibilità di id 3. Sarebbe meglio scriverlo sotto forma di

www.example.com/availability?user_id=3

come filtro sulla raccolta di disponibilità.

Per quanto riguarda la scelta, ritengo che entrambi siano validi, e puoi anche supportare entrambi con una singola funzione nel backend poiché sono entrambi lo stesso filtro.

www.example.com/users/3/availability/
www.example.com/availability?user_id=3

Oltre a @VoiceOfUnreason " answer .

Le API REST sono pensate per essere un ulteriore livello dell'applicazione, non l'applicazione stessa.

È un'interfaccia per le integrazioni. Come interfaccia vuoi che sia il più possibile disaccoppiato, quindi se il dominio cambia, l'API non deve necessariamente cambiare anche tu. Di conseguenza, i consumatori non devono preoccuparsi di questi cambiamenti.

Se l'API REST simula il modello di dominio a un livello così basso come le relazioni delle tabelle di basi di dati, quando si verificano cambiamenti, ognuno ne subisce le conseguenze. Una volta rilasciata l'API, cambiare la sua interfaccia è una delle cose peggiori da affrontare.

Ecco perché, in generale, è bene pensare nelle API REST come un'ulteriore astrazione nell'applicazione. Quindi, non (se possibile) esporre i dettagli dell'implementazione al mondo. Piuttosto, esporre le rappresentazioni.

Quando si modellano i modelli URI, cercare l'URI che informi meglio lo sviluppatore su cosa potrebbe aspettarsi dopo le richieste. Gli URI non hanno bisogno di essere leggibili dall'uomo, ma quando lo sono, rendono il lavoro dello sviluppatore un po 'più facile.

Dico sviluppatore , perché dal punto di vista del client (client dell'app) gli URI sono privi di significato.

Disponi le tue tabelle in uno schema separato, chiamalo data , crea un altro schema chiamato api e posiziona solo le viste che all'inizio sono solo specchi delle tue tabelle. mappa la tua API a quelle viste. ora hai i tuoi tavoli disaccoppiati dalla tua API, puoi cambiarne uno indipendentemente senza influenzare l'altro.

controlla anche PostgREST il tipo di API che stai costruendo può essere automatizzato, non è necessario farlo a mano