Une API RESTful doit-elle fournir des données pour un formulaire entier?

13

Disons que j'ai une application Web JavaScript qui utilise entièrement une API RESTful pour les données.

Disons que cette application a un formulaire de données, et disons que je modifie un enregistrement dans / product / 12345. Lors de la création du formulaire, je fais une demande RESTful à / product / 12345 et j'obtiens les données JSON:

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

Donc, mon formulaire peut évidemment avoir une liste déroulante pour sélectionner un vendeur. Je dois remplir cette liste. D'où les données doivent-elles provenir? Quelle est l'approche la plus courante?

Serait-il logique de l'intégrer à la réponse à la demande / 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"}
  ]
}

Qu'en est-il lors de la création d'un nouvel enregistrement? Mon API doit-elle également répondre à GET / product / new, avec les éléments suivants?

{
  "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
la source
veuillez ne jamais utiliser la demande GET pour créer quelque chose. Votre point de terminaison doit être / produit non / produit / nouveau . Pour créer un nouveau produit, vous devez envoyer une demande PUT à ce point de terminaison.
Kerem Baydoğan
Cela ne crée rien. Il s'agit purement d'une demande de données existantes ou d'un modèle pour un nouvel enregistrement, pas encore enregistré.
Chad Johnson
oh désolé, maintenant je vois ce que tu veux dire. Dans tous les cas, le point de terminaison du produit ne doit pas être responsable de la fourniture d'un modèle de produit ou d'une liste de valeurs pour les listes déroulantes des formulaires de création de produits. comme le dit @Dan, il suffit de créer des points de terminaison séparés et d'utiliser des en-têtes de mise en cache pour que votre navigateur puisse mettre en cache les valeurs déroulantes pour les performances.
Kerem Baydoğan

Réponses:

6

Je penche vers des points d'extrémité très simples et étroitement focalisés. Je m'attendrais à une demande à un endroit comme / sales_users qui renvoie tous les utilisateurs des ventes.

GET / 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"}
]

De même, si vous souhaitez avoir une liste de catégories, j'ajouterais un point de terminaison distinct pour cela.

GET / catégories:

[
    {"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"}
]

Je ne construirais pas un GET / produit / nouveau. Je créerais plutôt un formulaire dans votre application pour gérer l'ajout de nouveaux produits qui connaît les demandes appropriées pour remplir ses listes (par exemple, GET / categories, GET / sales_users, etc.).

Dan Lyons
la source
3

En supposant que la liste des vendeurs est relativement statique, je pense que vous voudriez un appel API distinct /salesusersque vous pourriez appeler une fois (au chargement du formulaire, etc.) et économiser afin de ne pas avoir à demander de nouveau ces données chaque temps. N'oubliez pas que dans REST, vous organisez votre API autour des ressources et les vendeurs sont logiquement des ressources distinctes des produits.

De même, lorsque vous appelez /product/new, vous souhaitez uniquement soumettre des données pour un nouveau produit, qui peuvent inclure un identifiant sales_user, mais rien de plus. Les modifications apportées à un sales_user lui-même constitueraient un appel distinct.

Dan1701
la source