6.9 Query on Intermediate URL
An SData consumer can also query an intermediate URL. See Intermediate URLs section. Here is an example:
GET /sdata/myApp/myContract/-
This request lists the resource kinds exposed by the test contract. A typical response will be:
200 OK
Content-Type: application/atom+xml; type=feed
<feed xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.w3.org/2005/Atom">
<title>Test contract for myApp production</title>
<id>http://www.example.com/sdata/myApp/myContract/-</id>
<updated>2008-03-31T13:46:45Z</updated>
<link rel="self" type="application/atom+xml; type=feed" title="Refresh"
href="http://www.example.com/sdata/myApp/myContract/-" />
<link rel="first" type="application/atom+xml; type=feed" title="First Page"
href="http://www.example.com/sdata/myApp/myContract/-" />
<link rel="last" type="application/atom+xml; type=feed" title="Last Page"
href="http://www.example.com/sdata/myApp/myContract/-" />
<link rel="http://schemas.sage.com/sdata/link-relations/schema"
type="application/xml" title="Schema"
href="http://www.example.com/sdata/myApp/myContract/-/$schema?version=5" />
<category scheme="http://schemas.sage.com/sdata/categories"
term="contract" label="Contract"/>
<opensearch:totalResults>15</opensearch:totalResults>
<opensearch:startIndex>1</opensearch:startIndex>
<opensearch:itemsPerPage>20</opensearch:itemsPerPage>
<entry>
<id>http://www.example.com/sdata/myApp/myContract/-/contacts</id>
<title>Contacts</title>
<updated>2008-03-31T13:46:45Z</updated>
<link rel="self" type="application/atom+xml; type=feed" title="self"
href="http://www.example.com/sdata/myApp/myContract/-/contacts" />
<link rel="http://schemas.sage.com/sdata/link-relations/schema"
type="text/xml" title="Schema"
href="http://www.example.com/sdata/myApp/myContract/-/$schema?version=5#contact" />
<link rel="http://schemas.sage.com/sdata/link-relations/service"
type="application/atom+xml; type=feed" title="Service"
href="http://www.example.com/sdata/myApp/myContract/-/contacts/$service" />
<category scheme="http://schemas.sage.com/sdata/categories"
term="collection" label="Resource Collection"/>
<content>Contacts</content>
</entry>
<entry>
<id>http://www.example.com/sdata/myApp/myContract/-/salesOrders</id>
<title>Sales Orders</title>
<updated>2008-03-31T13:46:45Z</updated>
<link rel="self" type="application/atom+xml; type=feed" title="self"
href="http://www.example.com/sdata/myApp/myContract/-/salesOrders" />
<link rel="http://schemas.sage.com/sdata/link-relations/schema"
type="text/xml" title="Schema"
href="http://www.example.com/sdata/myApp/myContract/-/$schema?version=5#salesOrders" />
<link rel="http://schemas.sage.com/sdata/link-relations/service"
type="application/atom+xml; type=feed" title="Service"
href="http://www.example.com/sdata/myApp/myContract/-/salesOrders/$service" />
<category scheme="http://schemas.sage.com/sdata/categories"
term="collection" label="Resource Collection"/>
<content>Sales orders</content>
</entry>
<!-- ... more entries ... -->
</feed>
The information returned by this query is somewhat redundant with the information found in the schema. See Metadata section. SData consumers that need all contract details SHOULD read the schema rather than query intermediate URLs. This way they get all the information at once, in a compact form (the schema describes the payloads). But consumers that only need basic information, such as a list of resource kinds and operation names MAY find it easier to query intermediate URLs than to analyze complete schemas.
Providers should do their best to respond with valid feeds to the various intermediate URLs listed in the Intermediate URLs section. As a general rule, providers should provide valid responses to the URLs at the contract level and below. Some infrastructures can make it difficult to respond to higher level URLs. For example, URLs that list applications and datasets. If the provider can’t list applications and/or datasets, it MUST respond with a 501 Not Implemented status to the URLs it does not support.
If the returned feed has a large number of entries, the feed SHOULD be paged. For example a provider with a large data model that exposes a large number of resource kind URLs. See Query Paging section.