The GetCapabilities operation provides access to general information about a live TJS implementation, and lists the operations and access methods supported by that implementation. TJS implementations must support the GetCapabilities operation via HTTP GET. Support for HTTP POST is optional.
|service||Required||Identifies service type. Must be "TJS".|
|request||Required||Identifies service request. Must be "GetCapabilities".|
|acceptVersions||Optional||Identifies service version. Comma-delimited string of version numbers supported by the client, in order of preference. Currently "1.0" is the only valid version number.|
|language||Optional||Determines the language of the human-readable content of the response. Consists of a list of RFC 4646 language tags, comma-delimited and in order of preference.|
HTTP GET method using KVP (mandatory)
HTTP GET requests supply the request parameters encoded as KVP pairs as part of the URL. An example of a GetCapabilities request via HTTP GET is:
Note: URL encoding of KVP values in this example has been removed for clarity.
HTTP POST method using XML (optional)
XML encoded GetCapabilities requests use the HTTP POST method with the body of the request (POST data) of type text/xml according to the GetCapabilities request XML schema. For example, a client may encode a GetCapabilities request in XML as follows:
<GetCapabilities service="TJS" language="en"/>
The normal response to a GetCapabilities request is a TJS Capabilities document. This document is encoded in XML according to the GetCapabilities response XML schema.
When a TJS server encounters an error while performing a GetCapabilities operation, it shall return an exception report message as specified in Clause 8 of [OGC 06-121r3]. The allowed exception codes shall include those listed in Table 5 of Subclause 7.4.1 of [OGC 06-121r3].
For more information on structuring requests, please see the TJS Standard.