-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: V4.01_CSD01
-
Fix Version/s: V4.01_CSD02
-
Component/s: Protocol
-
Labels:None
-
Environment:
Applied
-
Proposal:
-
Resolution:
1) Chapter 10 states: The context URL describes the content of the payload. It consists of the canonical metadata document URL and a fragment identifying the relevant portion of the metadata document.
This is somewhat violated by context urls using the template variable
{entity}whose value is the canonical URL of an entity, including its key values - the key values aren't needed to identify the relevant portion of the metadata document, for this purpose the type is sufficient.
2) Chapter 10 states: Request payloads generally do not require context URLs as the type of the payload can generally be determined from the request URL.
Can we have the same for response payloads? Most responses for requests to entity sets or singletons using canonical URLs would not need a context URL, same for navigation paths with a navigation property binding. Instances with a type derived from the declared type carry the @odata.type annotation, so even those don't need a context URL. Same for responses to actions/functions with an EntitySetPath, or action/function imports with a an EntitySet.
In Olingo the context URL is being used to figure out the Base URI of the entity in few places, other than that I have not seen usage of the other fragments of the URL else where in client.
Our SAP-internal OData core framework (used in mobility platform) sometimes relies on context URL to identify the entity type in responses (via the entity set name in the context URL, we can then obtain the entity type since we have the parsed metadata document available).
One use case is: the client application provides a query URL (rather than constructing it via a URL builder), and we want to instantiate entities of the correct type (e.g. proxy class instances) when parsing a response.
Our preference is for minimal metadata in responses, relying on service metadata document that we preload before sending any requests. But in cases where the minimal metadata might omit "@odata.type", we want to avoid the client having to parse its own query URL to determine what it is expecting to receive.
In any case, context URLs that would simply identify the entity type would be helpful. Since currently, we almost need a full-blown URL parser in the client to be able to parse context URLs.
Current rules for context URL and other parts of the response make the response body "self-contained", so e.g. navigation links can be constructed without having to know the request URL that produced that response.
Relaxing this could be achieved via a preference or format parameter.
Resolved as proposed to clarify objective of ContextUrl 2017-3-16.
Application approved 2017-6-8.
-ids are in context URL for relative references (and are particularly important for containment). Just using types would break that.
-Not returning context url in minimal would be breaking; it would have to be 4.01 only.The context URL is returned in minimal metadata because we wanted responses to be standalone.
-Client libraries may depend on context url to process results without having to know about the request url. we would have to make sure libraries had access to the request in order to correctly interpret the results.
Mike will look into impact on .NET libraries.
Ramesh will look into impact on Olingo libraries.
Matt will follow up with Evan.