Re: [search-ws] responseType Request and Response

[Ashley Sanders <a.sanders@manchester.ac.uk>]

Ralph wrote:

> 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.

I was going to suggest that a mime type of application/x-sru+xml
would conform better to current tastes for MIME types. SVG, Atom and
XHTML all use the +xml suffix. I guess it gives you the flexibility
to have something like application/x-sru+json should you feel so
inclined.

> 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.

A status code of 406 would seem appropriate. HTTP still allows
you to send a response document back to the client of any
content type you desire. The following document

   http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

says this:

       Note: HTTP/1.1 servers are allowed to return responses which are
       not acceptable according to the accept headers sent in the
       request. In some cases, this may even be preferable to sending a
       406 response.

So, if the requested content type isn't supported, you can just send
back the data in any format you like with a status code of 200.

Ashley.
-- 
Ashley Sanders               a.sanders@manchester.ac.uk
Copac http://copac.ac.uk A Mimas service funded by JISC