2

I have a domain model of a graph. When a user tried to modify it a cyclic check is performed and the appropriate http response code is returned.

However, we want to build a proposed change on the client and just check whether or not it's valid to the current state of the graph.

The code is simple enough. Just let the user POST the graphChangesToValidate to some validation method and my back-end service which already does this work can confirm whether or not it would be ok to make the changes...

My question is what HTTP status code(s) should I return in this case?

200 would imply that the proposed change passed validation. For failure I don't know if 400 is appropriate because the request is formatted fine and the server is just saying "I understood your request, the answer is no."

I'm thinking that as long as the validation method completes I should return a 200 with either a true or a false boolean in the content.

Is there a more standard way to handle this?

Matthew
  • 10,244
  • 5
  • 49
  • 104
  • A cool way of implementing this would be to have the POST for the changes be sent, then the server could return HTTP 100 (Continue) if the validation is ok, then the client can then send the final commit message. This would avoid disparate calls to make the change. And if the graph change is invalid, the server could return 409 as mentioned by @sanpaco – Edgar Aug 12 '15 at 00:56
  • @Edgar that's an interesting idea but doesn't the idea of a `HTTP 100` seem unRESTful? – Matthew Aug 12 '15 at 19:28
  • I guess it depends on if you consider this two phase approach a single stateless transaction or two separate stateful transaction. Seems like semantics to me. The value of RESTful APIs in my opinion comes from the statelessness and I think the HTTP 100 is just a slightly more complex request - just like any chunked form upload. – Edgar Aug 25 '15 at 04:07

2 Answers2

2

The status-codes usually don't give information about the content, but just that the request/response was successful according to the protocols (or not).

A (200) status code is part of the http header , what you are talking bout sounds like message content to me.

Having said that, you can use/abuse it any way you want as long the server and client agree on how to handle it. But it would be better to have some useful message that makes sense to other developers (and some API documentation).

Alex
  • 5,759
  • 1
  • 32
  • 47
1

The answer is... maybe. I personally have typically used a 200 with additional details in the response such as an error code with details of what validation steps failed. There are http codes in the 400 range that could also be used appropriately for validation errors.

Check this issue out for some good comments and discussion on it: Is returning HTTP 409 appropriate for a validation check?

I think that generally as long as the request is appropriately formatted and received, a 200 code should be used and then the business logic is what handles the validation error. If there is an error in formatting, then you could use a HTTP error as a response.

Community
  • 1
  • 1
sanpaco
  • 785
  • 1
  • 14
  • 32