SRU VIA HTTP GET
The client MAY send an SRU request via the HTTP GET method. A URL is constructed and sent to the server with fixed parameter names with fixed meanings. When unicode characters need to be encoded, there are some additional constraints, discussed below.
The response MUST be XML conforming to the response schema of the operation. SRU via HTTP GET can thus be described as the simplest case of XML over HTTP.
An example of what might pass over the wire:
GET /lcdb?version=1.2&operation=searchRetrieve&query=dinosaur HTTP/1.1
An SRU request (when transported via HTTP GET) is a URI as described in RFC 3986 (See Note 1). Specifically it is an HTTP URL (as described in section 3.3 of RFC 1738; however there are some further notes about character encoding below, and uses the standard & separated key=value encoding for parameters in the query part of the URI.
The parameters for the query section of the URL (the information following the question mark) of the various operations are described in their own sections.
The following encoding procedure is recommended, in particular, to accomodate Unicode characters (characters from the Universal Character Set, ISO 10646) beyond U+007F, which are not valid in a URI. This is normally relevant only to the query parameter of the searchRetrieve operation and the scanClause parameter of the scan operation.
Note: In step 2, it is recommended to percent-encode every character in a value that is not in the URI unreserved set, that is, all except alphabetic characters, decimal digits, and the following four special characters: dash(-), period (.), underscore (_), tilde (~). By this procedure some characters may be percent-encoded that do not need to be -- For example '?' occurring in a value does not need to be percent encoded, but it is safe to do so. If in doubt, percent-encode.
Consider the following parameter:
query=dc.title =/word kirkegård
The name of the parameter is "query" and the value is "dc.title =/word kirkegård"
Note that the first '=' (following "query") must not be percent encoded as it is used as a URI delimeter, it is not part of a parameter name or value. The second '=' (preceding the '/') must be percent encoded as it is part of a value.
The following characters must be percent encoded:
The resulting parameter to be sent to the server would then be:
1. RFC 1738 is obsoleted by RFC 3986. However, RFC 1738 describes the 'http:' URI scheme; RFC 3986 does not, instead indicating that a separate document will be written to do so, but it has not yet been written. So currently there is no valid, normative reference for the 'http:' URI scheme, and so the obsolete RFC 1738 is referenced. When there is a valid, normative reference, it will be listed here.
SRU VIA HTTP POST
Instead of constructing a URL, the parameters may be sent via POST to the server. The Content-type header MUST be set to 'application/x-www-form-urlencoded'. Compare to 'text/xml' for SRU via SOAP below, which can be used to distinguish the two transports at the same end point.
POST has several benefits over GET for transfering the request to the server. Primarily the issues with character encoding in URLs are removed, and an explicit character set can be submitted in the Content-type HTTP header. Secondly, very long queries might generate a URL for HTTP GET that is not acceptable by some web servers or client. This length restriction can be avoided by using POST.
The response for SRU via POST is identical to that of SRU via GET, an xml document.
An example of what might be passed over the wire in the request:
POST /lcdb HTTP/1.1
Content-type: application/x-www-form-urlencoded; charset=iso-8859-1
SRU VIA HTTP SOAP
(Note: "SRU via HTTP SOAP " is the former SRW)
SRU via SOAP is a binding to the SOAP recommendation of the W3C. In this transport, the request is encoded in XML and wrapped in some additional SOAP specific elements. The response is the same XML as SRU via GET or POST, but wrapped in additional SOAP specific elements.
The incremental benefits of SRU via SOAP are the ease of structured extensions, web service facilities such as proxying and request routing, and the potential for better authentication systems.
The specification tries to adhere to the Web Services Interoperability recommendations.
There are some differences regarding the parameters that can be transported via the SOAP binding.
Example SOAP request:
March 31, 2016