Status code for multiple resources?

[Jørn Wildt]

Hi

We are implementing a resource where the client can GET a specific person by social security number - but in some cases the system may contain more than one person matching the SSN which is considered an error in the dataset.

When the client does a GET by the SSN it will receive a redirect to a relevant person resource using status code 303 See Other.

But what should the server return when multiple persons are found? It is not a client error so 400 Bad Request seems inapropriate. We could return 500 Internal Server Error - but then the client developers will call us and ask why the server failed.

I have looked at 300 Multiple Choices which seems to express what we need - but the RFC states (https://tools.ietf.org/html/rfc7231#section-6.4.1):

The 300 (Multiple Choices) status code indicates that the target 

resource has more than one representation

The RFC talks about multiple representations of the same resource - but we have multiple resources, not multiple representations of the same resource. Would it be correct to use status code 300 anyway?

What would you recommend?

Kind regards, Jørn

[Eric Stein]

This is orthogonal to your problem, but it is not unheard of for SSNs to be stolen and used by multiple people at once. That's not a dataset error as much as you uncovering fraud.

As far as the response, by the spec-as-written I think it has to be 500. Your contract with the clients is that SSN uniquely identifies a person, but given known SSN x, it can't uniquely identify a person. A good response body explaining the error should help soften the support burden. I agree that 300 would be nice, and if you're willing to stretch the intent of the spec it might be a good choice. The intent is clearly for conneg, though.

I assume you don't control the dataset? It seems like it should be pretty easy to do a one-time query of the data to find any duplicate SSNs.

Eric

[Jørn Wildt]

Eric, thanks for your input. We decided that 300 would be to stretch the spec too much. But neither did we want to use 500 since I am pretty convinced that no one is going to read the error message and just report it to us as a bug instead.

In the end we chose 400 Bad Request. Client developers are used to accept this as an error on their behalf and actually read the error message. The reasoning here then goes "you asked for ONE person with SNN X - that was not possible, please try something else - and, BTW, here is a list of all the persons we found".

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.