8

I would like my API to have a validation-only request. For example, if I have a URL such as:

http://api.somesite.com/users/12345

and the user is filling out a form of information on a client that I will eventually PATCH/PUT/POST to that resource. As the user is filling out the form, I might want to send over their partially-complete updated representation over to the server periodically so I can display realtime validation of their input (e.g., "That username is already taken", "That password is too short").

There isn't a standard HTTP METHOD or HEADER that seems to allow for this behavior on that same resource. It seems my options are:

  1. Create a new subordinate resource for validation
  2. Use a custom header (x-somesite-validation-only) and PUT indicating that I want to validate but not save
Fleep
  • 429
  • 4
  • 11
  • Related question: http://stackoverflow.com/questions/8368931/how-should-i-design-a-restful-url-to-validate-an-object – suing May 18 '12 at 00:56
  • Great question. Just ran into this issue too, and I'm debating between the exact same two approaches. Leaning towards the header personally. Inspired by git's `--dry-run` parameter in many of its commands. – Aseem Kishore Dec 01 '12 at 16:49

2 Answers2

5

Some options

1) Use custom header
2) Put something in the query string indicating to validate only
3) Use Action URl e.g. \IndividualClient\123\actions\Validate\Invoke {section 19 here http://restfulobjects.files.wordpress.com/2011/11/restful-objects-spec-052.pdf}
4) Hierarchical URL e.g. \IndividualClient\123\Validation

From this post I find this advice

Do use POST whenever you have to do something that feels RPC-like Do use GET for things like calculations, unless your input is large, in which case use POST

With regard to your specific question, POST should be used for #4 and #5. These operations fall >under the "RPC-like" guideline above. For #5, remember that POST does not necessarily have to >use Content-Type: application/x-www-form-urlencoded. This could just as easily be a JSON or CSV >payload.

Here is what I'm considering:

This is the add of a resource :
user/validation
POST
Request:UserResource
Response:ValidationResult
Response Codes 200, 400. 404. 500

This is the update of a resource
user/204/validation
POST
Request:UserResource,
Response:ValidationResult Response Codes 200, 400. 404. 500

Community
  • 1
  • 1
suing
  • 2,808
  • 2
  • 16
  • 18
  • I ended up implementing something very similar to this, but in the interest of not rewriting my software router, I just made it part of the querystring: POST /user/204?validate – Fleep Jul 23 '14 at 18:05
0

Thrid option would be to implement a validation function on the client. This function would then send specific request when it need specific information.

For example, you don't really need to send a request to check if a password is too short. But you could send a single request to check if a username exists.

This is how validation is done with Ajax, which btw is using Restful API (HTTP):)

Samy Arous
  • 6,794
  • 13
  • 20
  • 1
    I would argue that AJAX necessarily uses HTTP as a transfer protocol, but doesn't necessarily have to implement RESTful practices as an API *in a meaningful way*. Saying "all HTTP is RESTful" misses the point. – Fleep Jul 23 '14 at 18:04
  • Also, I'm going to validate on the server-side anyway, and in the interest of not repeating myself, I'd much prefer to be able to keep my validation code standardized and in a single place. Realtime validation that impacts the UI, like password validation, would work well with thin, non-critical validation on the client-side. But it's not a replacement for what I am asking about above. – Fleep Jul 23 '14 at 18:14
  • That`s double the amount of development work (i.e. on client and server sides). – Pierre Apr 03 '17 at 12:06