SData URL

The SData URL is responsible for resource addressing and represents the tie-in with the REST architectural style. The current specification (Chapter 2: Anatomy of an SData URL) is fairly restrictive due to the initial, more normative approach adopted at the time.

The proposals presented in the upcoming sub-sections remove a number of current rules and restrictions. The intended effect is increased simplicity coupled with lending applications the ability to construct URLs that fit better with their natural structure and underlying technologies.

Liberalization of the URL structure up to the query component

In SData 2.0 the URL structure prior to the Query component is freely definable by the provider. This applies specifically to the existence and structure of the following URI Path¹ subcomponents as defined by SData in the Resource Collection URL section:

Virtual directory:
- MAY be ‘sdata’, which is preferred
- MAY be a set of several sub-segments
Contract name:
- MAY be omitted if it is the only contract to be exposed by the provider
- MAY comprise several sub-segments. A meaningful sub-segment is the contract version that an application MAY expose
Application name:
- MAY be provided. It is recommended that the application name be a part of the URL.
Dataset:
- MAY be omitted if only one dataset is supported by the provider
- MAY contain several sub-segments reflecting a hierarchical dataset selection structure
- The composition formalism described in 1.x standard remains valid

The requirements imposed by version 1.x (Section 2.1 Resource Collection URL) become guidelines² in SData 2.0, meaning that implementations are encouraged (but not forced) to act accordingly.

Reserved segments at the application level

In SData 2.0, none of the segments mentioned below are required - these MAY be present if required by the underlying contract:

$schema: amendment to the 1.x version that required the presence of the segment
$service: clarification to the 1.x version
$queries: clarification to the 1.x version
$batch: amendment to the 1.x version where the $batch segment was tied exclusively to a resource kind URL

The corresponding SData 1.x definitions are found under:

Schema requirement

In SData 2.0 the presence of the schema is optional. This applies equally to application-wide and resource kind schemas. SData 1.x required a schema to be present (see 2.7 Resource Schema URL). While it is recognized that schemas are a meaningful component in application-to-application scenarios, providing and maintaining a schema in most other scenarios is difficult and costly. SData 2.0 lifts the existing requirement and leaves it up to the contract to require the presence of a schema.

1. URI Path as defined in section 3 of RFC 3986
2. This is a ‘lesson learned’ from the practical experiences with implementations of the standard. It was recognized that the objective needs of products and contracts, in combination with the underlying development tools, do not easily conform to the 1.x requirements. The relaxation reduces the implementation and maintenance effort of delivery teams.