Un'API RESTful dovrebbe fornire dati per un intero modulo?

13

Diciamo che ho un'applicazione web JavaScript che utilizza interamente un'API RESTful per i dati.

Supponiamo che questa applicazione abbia un modulo dati e diciamo che sto modificando un record in / product / 12345. Quando compilo il modulo, faccio una richiesta RESTful a / product / 12345 e ottengo i dati JSON:

{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27
}

Quindi, il mio modulo ovviamente potrebbe avere un elenco a discesa per la selezione di un addetto alle vendite. Ho bisogno di popolare questo elenco. Da dove dovrebbero provenire i dati? Qual è l'approccio più comune?

Avrebbe senso renderlo parte della risposta alla richiesta / product / 12345?

{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27,
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ]
}

Che dire quando si crea un nuovo record? La mia API dovrebbe anche rispondere a GET / product / new, con il seguente?

{
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ],
  "categories": [
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
  ],
  "etc": [ ... ]
}

api rest forms

— Chad Johnson
fonte

per favore non usare mai la richiesta GET per creare qualcosa. Il tuo endpoint dovrebbe essere / product not / product / new . Per creare un nuovo prodotto è necessario inviare una richiesta PUT a tale endpoint.

— Kerem Baydoğan,

Questo non sta creando nulla. Questa è puramente una richiesta di dati esistenti o un modello per un nuovo record non ancora salvato.

— Chad Johnson,

oh scusa, ora capisco cosa intendi. in entrambi i casi l'endpoint del prodotto non dovrebbe essere responsabile della fornitura di un modello di prodotto o di un elenco di valori per i menu a discesa dei moduli di creazione del prodotto. come dice @Dan, basta creare endpoint separati e utilizzare le intestazioni della cache in modo che il browser possa memorizzare nella cache i valori a discesa per le prestazioni.

— Kerem Baydoğan,

6

Mi inclino verso endpoint molto semplici, focalizzati in modo ristretto. Mi aspetterei una richiesta in una posizione come / sales_users che restituisca tutti gli utenti delle vendite.

OTTIENI / sales_users:

[
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
]

Allo stesso modo, se hai intenzione di avere un elenco di categorie, aggiungerei un endpoint separato per quello.

OTTIENI / categorie:

[
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
]

Non vorrei creare un GET / product / new. Piuttosto, creerei un modulo nella tua app per gestire l'aggiunta di nuovi prodotti che conosce le richieste appropriate per popolare i suoi elenchi (ad esempio, GET / categorie, GET / sales_users, ecc.).

— Dan Lyons
fonte

3

Supponendo che l'elenco dei venditori sia relativamente statico, penso che vorresti una chiamata API separata /salesusersche potresti chiamare una volta (al caricamento del modulo, ecc.) E salvare in modo da non dover richiedere nuovamente questi dati ciascuno tempo. Ricorda che in REST stai organizzando la tua API in base alle risorse e i venditori sono risorse logicamente separate dai prodotti.

Allo stesso modo, quando chiami /product/new, vorresti solo inviare dati per un nuovo prodotto, che potrebbe includere un ID sales_user, ma niente di più. Le modifiche a un utente sales_ stesso sarebbero una chiamata separata.

— Dan1701
fonte