REST requests require Web Services parameters in addition to the operation-specific parameters you provide for each request. In general, these parameters are passed in using the following custom HTTP headers:
Header |
Description |
The clientID specifies the client identifier for your application. Your client must provide a valid clientID with each request. If the clientID is invalid, the request will be rejected. Contact the library system administrator to obtain a clientID for your application. clientID is a string (see xs:string). |
|
x-sirs-locale |
The locale specifies the locale that Web Services should use when returning the response. This may be a language code only (for example, “fr”) or a language and country code (for example, “fr_CA”). This parameter is optional. If you do not specify a value, the system default is used. Case is significant. Language codes are lowercase, country codes uppercase. locale is a string (see xs:string). |
x-sirs-sessionToken |
The sessionToken identifies an active Web Services session for a specific user with specific privileges and (optionally) a specific station policy (workstationID). A valid session token must be included in the message header for all privileged operations (see Privileged operations). A Web Services client obtains a session token by using the loginUser operation (see loginUser). You end a session using logoutUser (see logoutUser). sessionToken is a string (see xs:string). |
The following shows a sample REST custom HTTP header:
Content-Type: application/x-www-form-urlencoded; charset=utf-8
x-sirs-clientID: SymWSTestClient
x-sirs-locale: en
Content-Length: 24
User-Agent: Java/1.6.0_20
Host: 127.0.0.1:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
The “x-sirs-” prefix is used here to avoid potential naming conflicts in the header.
However, passing these parameters in the header has the following advantages:
• | It prevents potentially sensitive information from being stored in logs as part of the URL. |
• | It allows library system administrators to better secure their applications by restricting access based on specific headers or header values. |
You may also use the default HTTP header and send these header values through the browser URL. When doing this, you leave off the “x-sirs-” prefix. See Testing REST requests with a browser.
Depending on the library configuration, you may also pass in a significant portion of the header key as a parameter of a GET or POST request. For example,
GET /symws/rest/standard/lookupTitleInfo?titleID=12225&includeItemInfo=true&clientID=SampleID HTTP/1.1
Related topics
© 2009-2012 SirsiDynix