¿Cómo debería diseñar una URL RESTful para validar un objeto

Question

Sin alejarme del paradigma RESTful, ¿cómo podría modelar la validación de objetos de forma RESTful? Lo mejor es explicar el caso de uso teórico que se me ocurrió ...

Imagine que tiene un sistema con una capa web muy delgada que realiza llamadas a servicios RESTful de back-end. Digamos que un usuario visitó un formulario de registro y lo envió, la capa web enviaría los datos no validados directamente a un servicio de fondo y, si el servicio responde con errores de validación en formato JSON, estos pueden enviarse al usuario como HTML.

Sin embargo, imagina que queremos tener un comportamiento AJAX en el formulario. Por ejemplo, el usuario ingresa su dirección de correo electrónico y queremos validar el uso de AJAX, enviando un error al usuario si su dirección de correo electrónico ya está registrada.

¿Tendría sentido implementar una sola llamada para validar solo la dirección de correo electrónico, o podría enviarse y validarse todo el objeto en un servicio de fondo? En este último caso, ¿qué URL podría usar para validar únicamente un objeto, en lugar de crearlo realmente?

Answer 1

La validación de un único campo de formulario puede mejorar la experiencia del usuario mientras el usuario rellena el formulario, pero cuando se envía el formulario, validaría el objeto completo, porque es menos propenso a errores. La URL puede ser simplemente https://mysite.com/users/emailvalidator para validar el correo electrónico solamente (un solo campo), y el formulario puede enviarse POST a https://mysite.com/users (el objeto completo). En el primer caso, la URL dice claramente que el recurso que desea utilizar es un objeto que puede validar un correo electrónico.

Answer 2

En el pasado he utilizado la noción de una caja de arena subrecurso para hacer lo que está sugiriendo,

http://example.com/customer/23/sandbox 

Esto me permite a POST deltas y tienen los cambios aplicados y validados, pero no ha cometido realmente. Esto funciona bastante bien para los diálogos de tipo "guardar/cancelar" tradicionales.

Sin embargo, me pareció que tratar con esos deltas era un verdadero dolor, así que desarrollé un tipo de medio diferente que registraba una secuencia de eventos en el cliente y luego publicaba ese documento en el recurso de la zona de pruebas. Al reproducir la secuencia de eventos, pude actualizar y validar el recurso del lado del servidor de una manera más simple.

Más tarde me di cuenta de que realmente no necesitaba el recurso distintivo "sandbox" y ahora simplemente publico el documento de "secuencia de eventos" directamente en el recurso que está afectando. Tengo algunos datos en el documento en sí que determinan si los cambios van a ser permanentes o simplemente transitorios. Simplemente depende si el usuario ha presionado el botón guardar aún o no.