Chapter 9. Heritage Exchange Request Format

Table of Contents

9.1. GetCap Queries
9.1.1. GetCap Using HTTP GET
9.1.2. GetCap Using HTTP POST
9.2. GetData Queries
9.2.1. FISHXML_Request
9.2.2. sessionID
9.2.3. auth
9.2.4. username
9.2.5. password
9.2.6. charset
9.2.7. schema
9.2.8. request
9.2.9. service
9.2.10. type
9.2.11. dataset
9.2.12. queryset
9.2.13. query
9.2.14. object
9.2.15. operation
9.2.16. parameter
9.2.17. resultset
9.2.18. object
9.2.19. sort
9.2.20. object
9.2.21. start
9.2.22. limit

This chapter address the format and structure of queries made to a HEEP server. Most HEEP Queries are formed within and XML document using the FISHXML_Query schema, which are POSTed to a HEEP server for processing. The XML schema itself dictates the structure of the query (Section A.2, “Request Schema”, but notes are provided here for guidance. We have also provided an example FISHXML_Query within this document, and which is available for download at http://oxarchdigital.com/fish/hep/0.1/examples/example_request.xml This example is informative rather than normative, and subject to further changes and clarification..

The HEEP client shall be responsible for forming valid requests. If any element of the request is invalid, the server shall issue an exception.

9.1. GetCap Queries

HEEP server capabilities can be queried without XML using HTTP GET, where keyword/value pairs are passed through the URL. This is the only operation for which GET is supported.

9.1.1. GetCap Using HTTP GET

9.1.1.1. GET Parameters for GetCap Requests

Currently only the GetCap Operation is supported using HTTP GET. This section describes the structure of a GET GetCap request. GetCap requests can also be preformed using HTTP POST; see the section on 'Requests Using HTTP POST' for guidance, below.

9.1.1.1.1. VERSION

The VERSION parameter specifies the protocol version number. The format of the version number, and version negotiation between client and server, is discussed above. The parameter is optional, and when absent, the reply shall return the most recent version of which it is capable.

9.1.1.1.2. REQUEST

The REQUEST parameter specifies which Operation is being requested from the server. Although only GetCap is supported over HTTP GET, the all GetCap requests using HTTP GET shall employ the REQUEST parameter. This is to allow for use of the GET method if it is required for future request Operations.

9.1.1.1.3. SECTION

The SECTION parameter specifies which type of capability is requested. The GetCap reply format currently provides the following types:

  • Service: Service metadata

  • availabledata: available datasets provided by the Service

  • capabilities: capabilities for each Operation

  • all: all of the above (default)

The parameter is optional and all elements of the GetCap shall be provided when absent. Multiple parameters may be delimited by commas, subject to the notes on Parameter Lists, above.

9.1.1.1.4. EXCEPTIONS

The EXCEPTIONS parameter specifies the format in which exception (error) information it returned from the server. See Chapter 11, Heritage Exchange Exceptions Format. The parameter is optional; "text/xml" shall be assumed when it is absent.

9.1.1.1.5. GetCap Request Examples Using HTTP GET

Example 9.1. A default request

http://example.com/hep/?request=getcap

Here all defaults are assumed, so the resource URL is simply provided with defaults. All capabilities data is returned.

Example 9.2. Requesting specific capabilities

http://example.com/hep/?request=getcap&section=availabledata

This requests only information about the available datasets offered by a HEEP Service.

Example 9.3. Requesting multiple capabilities

http://example.com/hep/?request=getcap&section=availabledata,Service

This requests dataset metadata and Service information offered by a HEEP Service.

Example 9.4. Requesting specific exception format

http://example.com/hep/?request=getcap&exceptions=text/html

This all default data, but requests that exceptions are reported in HTML.

9.1.2. GetCap Using HTTP POST

Details will be provided here, but thery are largely documented below.