what http response code for rest service on put method when domain rules invalid

tags:

rest

views:

329

answers:

+1 Q:

what http response code for rest service on put method when domain rules invalid

What is the most appropriate response code to return when using the PUT method to update a resource, and the request contains some data that would invalidate the domain rules?

For example, a customer resource must have a name specified. If an agent tries to issue a PUT without supplying a name I don't want to update the resource, and I want to tell the caller that they need to supply a name.

What HTTP response code?

+2 A:

The response code is not related to the http method in this case. You should return the same status code as if it had been a POST request. I'd say you should use 400 or 409 (Note: See further discussion of the difference between the two in the comments).

troelskn 2010-02-03 09:39:22

I actually had 409 - Conflict written down.Though, looking at http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html under 400 - Bad Request "The request could not be understood by the server due to malformed syntax.". If you can check the business rules of a request, and know they are invalid, then surely it isn't malformed syntax?I vote 409.

rotary_engine 2010-02-03 09:59:04

While `409` is probably the most correct, the `X00` responses can also be seen as the generic response within a category. So `400` is less specific than `409`. It's not how they are defined, but de-facto that's often the interpretation.

troelskn 2010-02-03 10:13:08

500 is definitely not the right response in this case as it is the client that made the error, not the server. 409 is used for concurrency conflicts, not rule violations.

Darrel Miller 2010-02-03 13:25:25

@darrel Are you sure about the `409`? The spec features a concurrency conflict as an example, but I read it as being just one example of a broader category.

troelskn 2010-02-03 16:04:48

No I'm not sure, and I can find no confirmation. Even the Httpbis document which is intended to clarify Http 1.1 does not elaborate further http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-8.4.10

Darrel Miller 2010-02-03 16:44:43

If you remove the reference to 500, I'll remove my downvote :-)

Darrel Miller 2010-02-03 16:45:19

Fair enough - 500 is certainly the worst choice of the three.

troelskn 2010-02-03 18:55:59

Httpbis for 409 - "The request could not be completed due to a conflict with the current state of the resource.". Would rule violations be considered part of the resource state?

rotary_engine 2010-02-04 01:21:00

IE8 displays 408/409 as "The website is too busy to show the webpage".

rotary_engine 2010-02-04 10:07:33

+2 A:

I would return a 400. Strictly, this is for "malformed syntax" (not invalid data), but in practice the YouTube, Twitter, etc. use it for more generally "bad" requests.

Matthew Flaschen 2010-02-03 09:40:23

I believe that this response is now accepted as the correct response for invalid data also.

Darrel Miller 2010-02-03 13:22:39

Yes, that was my point in citing those APIs.

Matthew Flaschen 2010-02-03 15:29:59

Have a look through w3c's list. I would suggest 401 Unauthorized if you're going down this route. Personally I'd suggest that you handle this at a higher level of abstraction.

Jon Cage 2010-02-03 09:42:42

I don't see any connection to authorization. I think the best design is to use the status code to signal an unusual condition, then provide additional information (which higher levels can process) in the message.

Matthew Flaschen 2010-02-03 09:47:42

Requiring a username sounds like authorisation to me, but either way, it's still making use of a machanism which is designed to solve a different problem.

Jon Cage 2010-02-03 10:00:47

What do you mean, "handle this at a higher level of abstraction"?

rotary_engine 2010-02-03 10:02:52

It's not necessarily a username, imagine the customer also requires a date of birth, but wasn't supplied.

rotary_engine 2010-02-03 10:04:11

@rotary: By higher level of abstraction I mean this sort of thing might be better handled in whatever the OP is using to make these calls / handle them on the server (PHP? Python? Ruby?) to return a more specific error condition rather than bodging http responses. The OP only mentioned usernames, but I agree that if it were another data type, a different code might be more appropriate.

Jon Cage 2010-02-03 10:19:48

The only thing that goes across the wire is a HTTP request/response. Using HTTP status codes to describe the result of a request is absolutely the right thing to do.

Darrel Miller 2010-02-03 13:27:22

The relevant list is here: http://www.iana.org/assignments/http-status-codes

Julian Reschke 2010-02-03 19:30:29

+1 A:

How about 422?

"The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions."

RFC 4918, Section 11.2

Julian Reschke 2010-02-03 19:22:26

Sounds promising. I hadn't seen that code, it doesn't appear in most documentation.

rotary_engine 2010-02-04 01:16:51

That is part of WebDav, /not/ standard HTTP.

Matthew Flaschen 2010-02-04 06:49:26

Matthew, that comment doesn't make sense. There's a reason why status codes in HTTP are extensible, and why there's an IANA registry.

Julian Reschke 2010-02-04 09:01:56

The registry exists so different extensions don't claim the same numbers for different purposes. That doesn't mean you should just cherry-pick status codes from extensions.

Matthew Flaschen 2010-02-04 10:18:29

Well, it also doesn't mean you can't. I've had the discussion before with an author of RFC 2616 who agreed that 422 is a good thing and can absolutely be used outside WebDAV. If you disagree I'd recommend that you join the HTTPbis Working Group which, among other things, is chartered to clarify existing extension points when necessary.

Julian Reschke 2010-02-04 13:04:07

ansaurus

tags:

views:

answers:

what http response code for rest service on put method when domain rules invalid

related questions