4

I want to implement a REST endpoint which general purpose is to validate complicated entity in JSON format.

So, the first question is which HTTP method should be used? We can't put JSON into body for GET method. POST and PUT are methods that should be used when some changes are done to the DB but validation doesn't make any changes.

And the second question is what resource name can be appropriate for such endpoint?

evgeniy44
  • 2,862
  • 7
  • 28
  • 51

2 Answers2

3

The main difference between POST and PUT is that PUT is idempotent while POST isn't.

So, the question is, if you run the same validation request twice, would you expect a different result? I guess no, so PUT probably is the best choice.

I you want to be effectively RESTful, one of the constraint is that an endpoint should target the resource you want to deal with, the HTTP method indicating what you want to do with it. So in your case, I would personally opt for:

PUT /api/v42/validation

As @RomanVottner proposed, you could also tackle this need by considering each request as a "new validation report generation", in which case POST would be more appropriate:

POST /api/v42/validations

Anyway, you're facing one of these edge cases where REST needs to be a bit tweaked, as this need is outside of the CRUD world.

Graham
  • 7,431
  • 18
  • 59
  • 84
sp00m
  • 47,968
  • 31
  • 142
  • 252
  • 3
    I'd opt for `POST` as the semantics of the operation are defined by the API developer. The semantics of `PUT` would be: "Replace the state currently available at the given resource with the body sent with the request". As a validation service should obviously not replace the current state, `POST` is probably more suitable. In general, `POST`, the swiss-army-knife of HTTP; It can be used to start processes without having to create an actual resource, though its use-case is often limited to typical create-operations by confusing the intent of REST with CRUD-operations. – Roman Vottner May 31 '17 at 11:43
  • @RomanVottner You made some good points, `POST /api/v42/validations` could also nicely suit OP's need, as if a new validation report would be generated each time. OP meets one of these edge cases where REST needs to be tweaked a bit anyway ;) – sp00m May 31 '17 at 14:35
0

My general rule is.. when you need a full JSON body, go with POST.

Have a post method like /validateJSON or something, GET would not work, PUT doesn't make sense, so go ahead with POST.

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

Cheers.

Sam Upra
  • 737
  • 5
  • 12