¿Debería una API RESTful proporcionar datos para un formulario completo?

13

Digamos que tengo una aplicación web de JavaScript que utiliza por completo una API RESTful para datos.

Digamos que esta aplicación tiene un formulario de datos, y digamos que estoy editando un registro en / product / 12345. Al crear el formulario, hago una solicitud RESTful a / product / 12345 y obtengo datos JSON:

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

Por lo tanto, mi formulario obviamente puede tener una lista desplegable para seleccionar un vendedor. Necesito completar esta lista. ¿De dónde deben venir los datos? ¿Cuál es el enfoque más común?

¿Tendría sentido incluirlo en la respuesta de solicitud / 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é pasa al crear un nuevo registro? ¿Mi API también debe responder a GET / product / new, con lo siguiente?

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

Por favor, no use petición GET para crear algo. Su punto final debe ser / producto no / producto / nuevo . Para crear un nuevo producto, debe enviar una solicitud PUT a ese punto final.

— Kerem Baydogan

Esto no está creando nada. Esto es puramente una solicitud de datos existentes o una plantilla para un registro nuevo, aún no guardado.

— Chad Johnson

oh lo siento, ahora veo lo que quieres decir. de cualquier manera, el punto final del producto no debe ser responsable de proporcionar un producto de plantilla o una lista de valores para los menús desplegables de formularios de creación de productos. como dice @Dan, simplemente cree puntos finales separados y use encabezados de almacenamiento en caché para que su navegador pueda almacenar en caché los valores desplegables para el rendimiento.

— Kerem Baydogan el

6

Me inclino hacia puntos finales muy simples y de enfoque limitado. Esperaría una solicitud en algún lugar como / sales_users que devuelva todos los usuarios de ventas.

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

Del mismo modo, si va a tener una lista de categorías, agregaría un punto final separado para eso.

OBTENER / categorías:

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

No construiría un GET / producto / nuevo. Por el contrario, crearía un formulario en su aplicación para manejar la adición de nuevos productos que conozca las solicitudes apropiadas para llenar sus listas (por ejemplo, GET / categories, GET / sales_users, etc.).

— Dan Lyons
fuente

3

Suponiendo que la lista de vendedores es relativamente estática, creo que desearía una llamada a la API por separado /salesusersque podría llamar una vez (en la carga del formulario, etc.) y ahorrar para no tener que volver a solicitar estos datos cada uno hora. Recuerde que en REST, está organizando su API en torno a los recursos, y los vendedores son recursos lógicamente separados de los productos.

Del mismo modo, cuando llame /product/new, solo querrá enviar datos para un nuevo producto, que puede incluir una identificación de usuario de ventas, pero nada más. Los cambios en un sales_user sí mismo serían una llamada separada.

— Dan1701
fuente