Working with Web Services > Making REST requests > Custom HTTP headers

Custom HTTP headers

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

x-sirs-clientID

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