Rappresenta una relazione "Appartiene a" in un endpoint API

Question

Rappresenta una relazione "Appartiene a" in un endpoint API

#1 da (4 voti)
#2 da (3 voti)
#3 da (1 voti)

1

Considera i seguenti modelli di pseudo codice:

class Post
    int Id
    string Title
    int CategoryId
    Category Category

class Category
    int Id
    string Name

Si noti che Post appartiene alla categoria. Questo è ottenuto tramite una chiave esterna CategoryId su Post. Nel modello del post, c'è anche un oggetto Category.

Quindi le mie domande sono:

1. Su una richiesta GET per un post, come sarebbe il tuo JSON?

A - Solo la chiave esterna (questa sembra un po 'inefficiente se il valore per il nome della categoria è comunemente necessario)

{
  Id: 1,
  Title: 'My Title',
  CategoryId: 1
}

B - Solo l'oggetto nidificato

{
  Id: 1,
  Title: 'My Title',
  Category: {
    Id: 1,
    Name: 'General'
  }
}

C - Entrambi (come il modello attuale)

{
  Id: 1,
  Title: 'My Title',
  CategoryId: 1,
  Category: {
    Id: 1,
    Name: 'General'
  }
}

2. Considerando quanto sopra, cosa fai per un PUT / POST?

Non riesco a trovare esempi concreti di buone pratiche per rappresentare questo caso. Qualsiasi pensiero, guida o discussione benvenuto!

design api-design api json

posta matthewrk 20.03.2015 - 00:44

fonte

3 risposte

3

Strutturalmente, vorrei riconsiderare la nozione che un post appartiene a una categoria. È uno strano modo di modellare la relazione, soprattutto considerando che un post molto bene può formare una relazione con più categorie. Quindi nella mia mente un post ha più categorie.

Come @James Anderson ha iniziato, non dovresti pensare alla tua API come risultato della tua struttura di persistenza. Piuttosto, crea prima la tua API e poi scopri come interrogare il tuo livello di persistenza per formulare la risposta che desideri.

Se stavo progettando questa API, restituirei semplicemente un array di titoli di categoria come proprietà dell'oggetto post. Gli ID probabilmente non sono necessari.

Per POST e PUT puoi accettare titoli di categoria e associarli a ID sul back-end (restituendo un codice di errore o eventualmente creando una nuova categoria se un titolo fornito non esiste), o accettare un ID di categoria. In quest'ultimo caso, ti consigliamo di utilizzare un'API separata per ottenere tutte le categorie conosciute e i relativi ID.

risposta data 20.03.2015 - 01:28

fonte

1

Anche se sono d'accordo con James, a volte per qualsiasi motivo potresti voler avere oggetti, in modo da avere una rappresentazione migliore dei dati reali.

In questi casi, ci sono due considerazioni:

Avere solo CategoryId, se hai sempre o quasi sempre bisogno del nome, richiederà un'altra richiesta;
Avere entrambe le opzioni è abbastanza inutile poiché Post.CategoryId non è poi così diverso da Post.Category.Id , e hai una struttura che ha senso, non importa se hai matrici, oggetti o altro.

Tenendo conto di questi punti, in questo caso specifico andrei con gli oggetti nidificati. Hai un codice più pulito, puoi facilmente comprendere le strutture dei dati dal JSON (meno errori e più facile creare nuove cose o correggerle) e eviterai inutili duplicazioni nel codice e nell'oggetto JSON.

Tuttavia, è sempre bene ricordare che oggetti a volte nidificati potrebbero non essere l'opzione migliore, dal punto di vista delle prestazioni. È solo questione di cosa funziona meglio per la tua situazione specifica.

risposta data 20.03.2015 - 01:23

fonte

Leggi altre domande sui tag design api-design api json

In che modo Rust è un linguaggio "concorrente"? Come vengono eseguiti i linguaggi dichiarativi da un computer?

score 4 · Accepted Answer

Penso che tu stia partendo dalla parte sbagliata. La progettazione dell'API riguarda ciò che il cliente / richiedente non richiede sul modo in cui rappresenti i dati internamente.

Se il cliente ha bisogno del nome della categoria, basta fornirlo insieme all'ID (se è utile al client). Dato che un post appartiene a una sola categoria, non c'è motivo di avere qualcosa di diverso da una struttura piatta.