[OASIS Issue Tracker] (ODATA-799) Define Key-As-Segment URL convention for resource paths

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/ODATA-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61126#comment-61126 ] 

Mark Stafford commented on ODATA-799:
-------------------------------------

To build on Mike's response, let me elaborate what we're experimenting with in the .NET libraries we produce. Internally, we are discussing a change to the library in which a URL segment is interpreted based upon precedence rules. The goal would be to interpret a path like this without requiring the full, unambiguous OData syntax: ~/entityset/typecast/key/collectionnav/operation/key/typecast.

The precedence rules we are proposing for the segment following a collection are:
1. A hook that developers can use to override the precedence-based interpretation of what the segment is
2. $ref or $count
3. Operation
4. Type cast
5. Key

For a singular resource the precedence rules we are proposing are:
1. A hook that developers can use to override the precedence-based interpretation of what the segment is
2. $ref or $value
3. Declared property
4. Operation
5. Type cast

We are also relaxing the strictness of our parser so that URLs are not case-sensitive nor do we *require* namespacing. In the real world this should enable developers to use "friendlier" URLs as shown below.
Before: ~/Me/NS1.Manager/DirectReports('alak')/NS1.GetFavorites()/
After: ~/me/ns1.manager/directreports/alak/getfavorites
Note that we still needed the namespace on the second segment since the unqualified type cast conflicted with a property name in our fictional model. In general we are recommending that service authors do everything they can to avoid such duplication by changing property names or type names in their model.

Our libraries will continue to support the proper OData syntax and we always encourage the developers we talk to to use the unambiguous syntax. This just provides an option where 1) proper OData clients will continue to work and 2) service authors can opt in to a syntax which has less of a learning curve if that's important to their consumers.

> Define Key-As-Segment URL convention for resource paths
> -------------------------------------------------------
>
>                 Key: ODATA-799
>                 URL: https://issues.oasis-open.org/browse/ODATA-799
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData URL Conventions
>    Affects Versions: V4.0_ERRATA02
>         Environment: Simplified Syntax
>            Reporter: Ralf Handl
>            Assignee: Michael Pizzo
>              Labels: AdoptionBlocker
>             Fix For: V4.01_WD01
>
>
> Typical web APIs use path segments for key access to collection elements:
> ~/Users
> ~/Users/42
> Specify how such a URL convention would look like, considering
> - multi-part keys
> - the Edm primitive type system
> - bound actions/functions on entity-set level
> - context URLs for contained entities which include the key
> - relative context URLs
> Consider notation that allows context URLs to be relative to the service root.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)