responseType Request and Response

["LeVan,Ralph" <levan@oclc.org>]

Our new responseType parameter is used to specify the mime type of the response.  The REST community would say that we are tunneling something that should have been passed in an Accept header.

 

In the best of all worlds, we wouldn’t need the responseType parameter.  The client would simply send the mime type of application/x-sru+xml (or application/rss+xml) to the server and it would return the appropriate response.  Theoretically, this would be doable in SRW 1.2.

 

But, we don’t live in that best of all possible worlds.  I want to be able to use OpenSearch to query an SRU server.  Since I can’t specify accompanying HTTP Headers in my OpenSearch description document, I have no way to tell my SRU server that it must return an RSS response to the OpenSearch client.  So, we need that responseType parameter so that we can tunnel the Accept Header information through to the server.

 

But, what to do when the client requests a mime type that the server doesn’t support?  The correct response code seems to be “406 Not Acceptable”.  This tells the client that it asked for an unsupported mime type.  The W3.org documentation suggests that the response should include pointers to the requested resource in supported mime types, but does not say how that should be done; there are no standards in place to support that behavior.

 

So, I have two proposals.

 

First, if a responseType parameter has been sent and it specifies an unsupported mime type, then the server should respond with a 406 status code and might want to return an HTML message with pointers to that resource in supported mime types.

 

Second, we might want to consider wording in the standard that indicates that the intent of the responseType parameter can be accomplished with an Accept Header and that server developers ought to support it.  I don’t feel strongly about this second proposal, but I will be implementing it myself.

 

Ralph