Which REST operation (GET, PUT, or POST) for validating information?

Question

My users enter a few information fields in an iOS app. This information must be validated on my server, which has a RESTful API. After validation the UI of the iOS app changes to indicate the result.

Neither GET, PUT, or POST seem to be appropriate, because I'm not getting a resource, and neither is a resource created or updated.

What is the best fitting REST operation to implement this validation?

I had to really think about this one. Very good question. +1 — Kristian, Aug 13 '13 at 21:07

score 14 · Answer 1 · answered Aug 13 '13 at 21:02

14

I use the same scenario as you and use PUT for it. You have to ask yourself: "when I send the same request twice, does this make a different state on server?" If yes, use POST, if no use PUT.

answered Aug 13 '13 at 21:02

Lukas K

6,037
4
23
31

`PUT` against which URI? – Aug 14 '13 at 08:13
for example **/Login** (No metter how many times you login, the server stays still the same) – Lukas K Sep 06 '13 at 07:28

score 10 · Accepted Answer · answered Aug 13 '13 at 21:02

10

My users enter a few information fields in a iOS app. This information must be validated on my server, which has a RESTful API. After validation the UI of the iOS app changes to indicate the result....I'm not getting a resource, and neither is a resource created or updated.

Since you aren't saving anything (not modifying any resource), I'd think this is technically more RPC than RESTful to me.

The following is my opinion, so don't take it as gospel:

If the information is simply being submitted and you're saying yes or no, and you're not saving it, I'd say POST is fine..

If information were actually being saved / updated, then choosing the proper HTTP method would be a lot more relevant.

POST = CREATE / SUBMIT (in an RPC context)
PUT = UPDATE (or CREATE if there is nothing to UPDATE)

answered Aug 13 '13 at 21:02

Kristian

21,204
19
101
176

Thanks for the answer! Indeed it smells lik RPC. Even the URL ends in `/check` at the moment. But of course I don't want to mix in one SOAP RPC or something ;-) – meaning-matters Aug 14 '13 at 05:09
[This](http://stackoverflow.com/a/12100416/1971013) and other posts ;-) confirm what you say. Issue seems to be that there is no clear theoretical answer, and that it's a practical/interpretation thing. – meaning-matters Aug 14 '13 at 05:29
2

thanks for following up with that useful link. good luck. PS, check out Apigee.com, they do API discussions and how-tos... they once talked about good API structure, and they made note that you *can* include RPC-style methods that decorate existing routes... i.e. RESTFUL normal method: `/resource(/:id)` and RESTFUL decorated with RPC: `/resource/check` which accepts the params you're validating / checking – Kristian Aug 14 '13 at 14:39
2

In addition mind also about the returning status code: When the POST is to create it should answer with 201 (Created) while in your case (RPC) I think you are free to return 200 (Ok) or, as always, 400 (Bad Request). – Plap Jun 24 '16 at 12:55

score 9 · Answer 3 · answered Aug 14 '13 at 08:10

I recommend using a ValidationResource and two requests. Each instance of this resource represents the validation of a set of data. The workflow:

1. Create new ValidationResource

Request: POST /path/to/validations
- data to validate as the body
Response: 201 Created
- Location: /path/to/validations/<unique-id-of-this-validation>

2. Look up result

Request: GET /path/to/validations/<unique-id-of-this-validation>
Respons: 200 OK
- body: {'valid': true} or {'valid': false}

This is a RESTful approach in which the Validation is a Resource with server state.

score 3 · Answer 4 · answered Aug 13 '20 at 12:59

Google proposes use of Custom Methods for REST API

For custom methods, they should use the following generic HTTP mapping:

https://service.name/v1/some/resource/name:customVerb

The reason to use : instead of / to separate the custom verb from the resource name is to support arbitrary paths. For example, undelete a file can map to POST /files/a/long/file/name:undelete

Source: https://cloud.google.com/apis/design/custom_methods

So for validation the URL should be POST /resource:validate

score 1 · Answer 5 · answered Oct 04 '21 at 16:14

1

I believe it is similar to GET entity but since we need to send data to validate and sending confidential data in URL is wrong habit as only payload data is ciphered by TLS, the only way left is POST or PUT.

However you may save or update the data in validate(eg. "verified":false). Based on requirement, you can go for POST or PUT (recommended POST if no update)

 POST /user/validate-something

answered Oct 04 '21 at 16:14

arjun kumar

467
5
12

https://stackoverflow.com/questions/323200/is-a-https-query-string-secure – alex Jan 27 '23 at 10:12

score -1 · Answer 6 · answered Jun 09 '21 at 11:01

It seems like you're not doing it the correct way, if the validation is at the server-side then it should happen while submitting the data using a POST method. Then you'll validate that data, if validation fails then you can raise a 400 BAD REQUEST error, else you can create the resource.

This approach is more RESTful, as the POST method is properly used to create a resource or to raise 400 if validation fails

Which REST operation (GET, PUT, or POST) for validating information?

6 Answers6

Linked

Related