Uma API RESTful deve fornecer dados para um formulário inteiro?

13

Digamos que eu tenha um aplicativo da Web JavaScript que use inteiramente uma API RESTful para dados.

Digamos que este aplicativo tenha um formulário de dados e digamos que estou editando um registro em / product / 12345. Ao criar o formulário, faço uma solicitação RESTful para / product / 12345 e obtenho dados JSON:

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

Portanto, obviamente, meu formulário pode ter uma lista suspensa para selecionar um vendedor. Eu preciso preencher esta lista. De onde devem vir os dados? Qual é a abordagem mais comum?

Faria sentido fazer parte da resposta da solicitação / 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"}
  ]
}

E quando criar um novo registro? Minha API também deve responder a GET / product / new, com o seguinte?

{
  "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

por favor, não use GET solicitação para criar alguma coisa. Seu terminal deve ser / product not / product / new . Para criar um novo produto, você deve enviar uma solicitação PUT para esse terminal.

— Kerem Baydoğan

Isso não está criando nada. Isso é apenas uma solicitação de dados existentes ou um modelo para um novo registro ainda não salvo.

— Chad Johnson

oh desculpe, agora eu entendo o que você quer dizer. de qualquer forma, o terminal do produto não deve ser responsável por fornecer um modelo de produto ou lista de valores para os menus suspensos de criação de produtos. como o @Dan diz, basta criar pontos de extremidade separados e usar cabeçalhos de cache para que seu navegador possa armazenar em cache os valores suspensos de desempenho.

— Kerem Baydoğan

6

Eu me inclino para pontos finais muito simples e com foco restrito. Eu esperaria uma solicitação em algum local como / sales_users que retorne todos os usuários de vendas.

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

Da mesma forma, se você tiver uma lista de categorias, eu adicionaria um ponto de extremidade separado para isso.

GET / categorias:

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

Eu não criaria um GET / produto / novo. Em vez disso, eu criaria um formulário no seu aplicativo para lidar com a adição de novos produtos que conhecem as solicitações apropriadas para preencher suas listas (por exemplo, GET / categorias, GET / sales_users etc.).

— Dan Lyons
fonte

3

Supondo que a lista de vendedores seja relativamente estática, acho que você desejaria uma chamada de API separada para a /salesusersqual você poderia ligar uma vez (no carregamento do formulário etc.) e economizaria para não precisar solicitar novamente esses dados cada Tempo. Lembre-se de que no REST você está organizando sua API com base nos recursos, e os vendedores estão logicamente separando recursos dos produtos.

Da mesma forma, ao ligar /product/new, você gostaria apenas de enviar dados para um novo produto, que pode incluir um ID de sales_user, mas nada mais. Alterações no próprio sales_user seriam uma chamada separada.

— Dan1701
fonte