2.7 Resource Schema URL

Every contract MUST have an associated schema that describes the XML payloads for the resources and service operations exposed by the service. So, every contract MUST have a $schema URL such as:

http://www.example.com/sdata/myApp/myContract/-/$schema

Example	Component Name	Description / Comments
$schema	Schema keyword	Special syntax to designate a schema

This URL returns the schema for the test contract in XSD format.

The service MUST also support a $schema URL on every resource kind. For example, accounts and contacts feeds will have links to the following schema URLs:

http://www.example.com/sdata/myApp/myContract/-/accounts/$schema?version=1.0.7
http://www.example.com/sdata/myApp/myContract/-/contacts/$schema?version=1.0.7

Schema links MAY include a version parameter. This enables consumers to cache them more efficiently. See Resource Versioning section for details.

These last URLs SHOULD redirect to fragments in the contract schema. For example, the accounts/$schema URL above should return the following redirection response:

302 Found
Location: http://www.example.com/sdata/myApp/myContract/-/$schema?version=1.0.7#account
Expires: Thu, 06 Aug 2009 16:00:00 GMT

To get the account resource definition, the service consumer should query the global schema (test/$schema?version=1.0.7) and search for an element definition with id account inside the global schema.

The SData service SHOULD set the HTTP caching headers appropriately to allow service consumers to cache schemas. See Resource Versioning section and Caching section.

If a schema imports or includes schema fragments, the schema fragments SHOULD be exposed as sub-resources of their primary $schema resource (see Importing and including schemas). A typical fragment URL will be:

http://www.example.com/sdata/myApp/myContract/-/$schema/common

SData providers MUST support $schema URLs at the contract and resource kind level, as described above.

---