Non contained entity collections are generating paths to the entities

[darrelmiller]

Using Microsoft Graph v1.0 metadata the following paths are generated:

However many of these navigation properties are non-contained:

and therefore there should be no path to those entities. All of the paths that have the {directoryobject-id} parameter should not be created.

[darrelmiller]

I think the issue is here:

OpenAPI.NET.OData/src/Microsoft.OpenApi.OData.Reader/Edm/ODataPathProvider.cs

Lines 220 to 244 in f08180c

	if (!navigationProperty.ContainsTarget)
	{
	// Non-Contained
	// Single-Valued: DELETE ~/entityset/{key}/single-valued-Nav/$ref
	// collection-valued: DELETE ~/entityset/{key}/collection-valued-Nav/$ref?$id ={ navKey}
	ODataPath newPath = currentPath.Clone();
	newPath.Push(ODataRefSegment.Instance); // $ref
	AppendPath(newPath);
	}
	// append a navigation property key.
	IEdmEntityType navEntityType = navigationProperty.ToEntityType();
	if (navigationProperty.TargetMultiplicity() == EdmMultiplicity.Many)
	{
	currentPath.Push(new ODataKeySegment(navEntityType));
	AppendPath(currentPath.Clone());
	if (!navigationProperty.ContainsTarget)
	{
	// TODO: Shall we add "$ref" after {key}, and only support delete?
	// ODataPath newPath = currentPath.Clone();
	// newPath.Push(ODataRefSegment.Instance); // $ref
	// AppendPath(newPath);
	}
	}

I think line 228 should have an else. If the navigation property is not contained then we should not try and append a key to the path.

Thoughts? @xuzhg

[darrelmiller]

So, it turns out this isn't a bug, but it is a very useful convention. In order to minimize the number of operations generated in the OpenAPI document it seems unnecessary to enable accessing items of a collection by key from a non-contained collection because the canonical URL will have its own operation.

However, for non-contained collections it does seem useful to return a collection of $refs so that a consumer could identify all the canonical URLs of the referenced entities.