How do I create a RESTful URL to validate an object

Without breaking the RESTful paradigm, how could you model object validation in RESTful? It’s best to explain the theoretical use case that I came up with ...

Imagine you have a system with a very thin web layer that calls calls to RESTful internal services. Let's say that the user visited the registration form and submitted it, the web layer sends the unapproved data directly to the background server, and if the service responds to validation errors in JSON format, they can be sent back to the user as HTML.

However, imagine that we want to have AJAX behavior in the form. For example, a user enters his email address, and we want to verify it using AJAX, sending an error to the user if their email address is already registered.

Does it make sense to implement a single call to check only the email address, or can the whole object be sent and verified in the internal system? If the latter, what URL could you use only to validate the object, and not to create it?

+7
source share
2 answers

In the past, I used the concept of a sandbox sub-resource to do what you offer,

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

This allows me to share the "POST" and apply the changes and check, but not actually execute. This works well for traditional save / cancel dialogs.

However, I found that these deltas are a real pain, so I developed another type of media that recorded the sequence of events on the client, and then posted this document in the sandbox resource. By repeating the sequence of events, I could simplify updating and checking the resource on the server side.

Later, I realized that I really didn’t need a separate sandbox resource, and now I just send the “sequence of events” document directly to the resource that it affects. I have some data in the document itself that determines whether the changes will be permanent or just temporary. It only depends on whether the user clicked the save button or not.

+2
source

Confirming one form field can improve the user experience when the user fills out the form, but when the form is submitted, I would check the entire object because it is less error prone. The URL can simply be https://mysite.com/users/emailvalidator to only check email (one field), and the form can be sent to https://mysite.com/users (the entire object). In the first case, the URL clearly indicates that the resource you want to use is an object that can check email.

0
source

All Articles