Nasconde la complessità dei client API unendo le risorse a una pratica corretta?

Question

Nasconde la complessità dei client API unendo le risorse a una pratica corretta?

#1 da (1 voti)

2

Quindi supponiamo di avere tre semplici risorse: gruppi, utenti e utenti di gruppo.

Groups - Represent interest groups which can be subscribed by users.
{
    name: 'Colorado Mountain Biking Group'
    ownerId: 1 (Some user)
}

GroupUsers - Represents the junction table in the many to many Groups - Users relationship. Group membership status and some other attributes are stored here. 
{
    userId: 2,
    courseId: 1,
    color: '#FFFFFF',
    nickname: 'MBG Colorado',
    status: 'accepted'
}

Poiché il nostro client API gestirà sempre il gruppo dalla prospettiva dell'utente autenticato, GET /api/groups/1 AUTH(userId=2) dovrebbe restituire:

  Group (Includes GroupUser for authenticated user)
  {
      id: 1
      name: 'Colorado Mountain Biking Group'
      ownerId: 1,
      groupUser: {
          userId: 2,
          courseId: 1,
          color: '#FFFFFF',
          nickname: 'MBG Colorado',
          status: 'accepted'
      }
  }

Qualcuno mi ha suggerito che i nostri client API non dovrebbero conoscere o preoccuparsi della tabella di giunzione, tutto quello che dovrebbero interessare è il gruppo, quindi dovrei rispondere con una risorsa unita in questo modo:

  group (In reality group merged with groupUsers for the authenticated user.)
 {
      id: 1
      name: 'Colorado Mountain Biking Group'
      ownerId: 1,
      userId: 2,
      color: '#FFFFFF',
      nickname: 'MBG Colorado',
      status: 'accepted'
 }

Il problema che vedo con questo (oltre a unire problemi come ID ripetuto e timestamp creati / aggiornati / ora) è che i client API utilizzeranno la stessa risorsa per interagire ulteriormente con i nostri endpoint API.

Se un client API desidera aggiornare la risorsa groupUser, vorrebbe:

PUT /api/groups/1 
{
      id: 1
      name: 'Colorado Mountain Biking Group'
      ownerId: 1,
      userId: 2,
      color: '#000000',
      nickname: 'Some other value',
      status: 'accepted'
 }

Così ora avremmo anche bisogno di scansionare i corpi delle richieste e differenziare gli attributi group e groupUser. Ne vale la pena? Anche quando i consumatori di API sono altri sviluppatori interni?

api rest

posta RedHusky 23.05.2015 - 00:35

fonte

1 risposta

Leggi altre domande sui tag api rest

Modelli di design: estrai i tipi di istanza in diversi bucket Come contare gli hit in un'API HTTP senza appesantire il DB

score 1 · Answer 1

Stai affrontando un compromesso tra due principi di progettazione:

prima, semplicità / consistenza : il tuo approccio originale ha il vantaggio che i nomi e la struttura corrispondono meglio alle tue strutture lato server, cosa che ti risparmia un po 'di mappatura. Ad esempio, immagina di introdurre un attributo colore nella risorsa Group in seguito. Quindi il tuo primo approccio ora creerà un conflitto di denominazione, che deve essere risolto nella mappatura.
in secondo luogo, la progettazione dell'API dovrebbe essere eseguita principalmente da il punto di vista del client , a prescindere da cosa lo serva meglio. Seguendo questo principio, il secondo approccio è migliore (a condizione che funzioni e lo sforzo aggiuntivo non sia irragionevole).

Quindi devi prendere una decisione su ciò che è più importante per te e per i tuoi colleghi, nel tuo ambiente. Il primo approccio potrebbe produrre uno sforzo leggermente maggiore per qualcun altro, il secondo un po 'più di sforzo per te.