Previous Page Arrow Next Page Arrow

2.9 Intermediate URLs

URLs are hierarchical by nature. Previous pages describe terminal URLs that correspond to resource collections, resources, service operations, schemas, etc. Terminal URLs are the primary URLs that an SData consumer uses to interact with a provider. But a consumer may also try to access intermediate URLs such as:$service$service$queries

An SData provider SHOULD support GET operations on these URLs. If so, it MUST respond with an Atom feed that lists the branches available at the intermediate level of the URL hierarchy. The entries of the returned feed SHOULD be tagged with Atom categories so that the consumer can find out if the entries describe collection URLs, single resource URLs, service operation URLs, etc.

The following table gives an overview of the feeds returned by these intermediate URLs, as well as the categories that the provider should use to tag the feed and its entries (see SData Scheme section):

URL Feed Content Feed-level Category Entry-level Category Lists applications. Provider Application Lists contracts supported by the myApp application. Application Contract Lists datasets available for the myApp/myContract contract. Contract Dataset Lists resource collections exposed by the prod dataset for the test contract Dataset Collection$service Lists service operations exposed by the prod dataset for the test contract. Service Operation$queries Lists named queries exposed by the accounts resource kind. Queries Query
SData providers SHOULD support these URLs. There may nevertherless be constraints that prevent them from implementing the topmost intermediate URLs. For example, in a Tomcat deployment, it is likely that every contract will be handled by a different servlet. Then, the contract servlet should be able to list the datasets but there will not be any servlet to list the contracts. In this scenario, intermediate URLs will only be supported at the contract level and below.

Previous Page Arrow Next Page Arrow