I have an application that sends messages to users. In a post request a XML string is transferred that consists of all the users that should receive that particular message.
I've dealt with a very similar issue. In this case, I returned a
207 Multi-Status
Now, this isn't strict HTTP, it's part of the WebDAV extension, so if you don't have control over the client too, then this isn't good for you. If you do, you could do something like so:
<?xml version="1.0" encoding="utf-8" ?>
<D:multistatus xmlns:D='DAV:'>
<D:response>
<D:user>user-123</D:user>
<D:status>success</D:status>
</D:response>
<D:response>
<D:user>user-789</D:user>
<D:status>failure</D:status>
</D:response>
</D:multistatus>
But again, this is an HTTP extension, and you need to have control of the client as well.
The HyperText Transfer Protocol deals with the transmission side of things. It doesn't have error codes to deal with application level errors.
Returning 200 is the right thing to do here. As far as HTTP is concerned the request was received properly, handled properly and you're sending the response back. So, on the HTTP level everything is OK. Any errors or warnings related to the application which running on top of http should be inside the response. Doing so will also prevent some nasty issues you might run into with proxy servers which might not handle certain responses the way you expect.
I've had the same problem, and I've ended up using two different solutions:
202: Accepted
, indicating that the request was ok, but there's no guarantee everything actually went as it should.200
in the response, but include a list of what didn't pan out in the response body.The second one usually works best, but the first one is great if you're lazy or use a queue for processing.
What about using 206 Partial Content. I know 206 is more about ranges, but what if it could indicate a partially successfully request?