[OASIS Issue Tracker] Commented: (ODATA-412) Consistent representation of empty values

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

    [ http://tools.oasis-open.org/issues/browse/ODATA-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33594#action_33594 ] 

Michael Pizzo commented on ODATA-412:
-------------------------------------

Actually, current semantics are more inconsistent than that.

When we try to index an entityset by key, as in ~Customers('nonexistentkey') we currently return 404 NOT Found. This is particularly strange when you consider containment, because the canonical URL (which we say returns 404 NOT FOUND if the item doesn't exist) is the navigation link (which we say returns 204 no content if the item doesn't exist).

I think it would be highly surprising to a client to get a 200 with no content, especially for resources that don't exist (i.e., GET ~Customers('bogus'))

I would propose instead that we consistently use 404 NOT FOUND to indicate the following conditions:
1) Index within an entityset (i.e., ~Customers('NonExistingCustomer') )
2) Id Look up within null valued contained to-many navigation properties (i.e., ~Orders(10)/Details(7) where OrderDetail(7) does not exist within Orders(10))
3) Id Look up within null valued (non-contained) to-many navigation properties (i.e., ~Customers('ALFKI')/Orders(10) where Orders(10) does not exist within ALFKI's collection of orders)
4) Null valued to-one navigation properties (i.e., ~Customers('ALFKI')/SalesPerson where SalesPerson is a 0..1 navigation property whose value is null)
5) Null valued complex properties (i.e., ~Customers('ALFKI')/Address where Address is a complex type)
6) Null valued primitive properties (i.e., ~Customers('ALFKI')/FavoriteColor where ALFKI doesn't have a favorite color)

> Consistent representation of empty values
> -----------------------------------------
>
>                 Key: ODATA-412
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-412
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData ATOM Format , OData JSON Format, OData Protocol 
>    Affects Versions: V4.0_CSD01
>         Environment: [Proposed]
>            Reporter: Ralf Handl
>             Fix For: V4.0_CSD02
>
>
> We currently use different representations for empty values.
> The consistent cases are:
> - empty collections of primitive values, complex values, and entities are represented with 200 OK and the format-specific representation of an empty collection of the appropriate type (<m:value/>, <atom:feed/>, {"value":[]})
> - empty primitive values in Atom and JSON are represented with 200 OK and the format-specific representation of a null value (<m:value m:null="true"/> or {"value":null})
> - empty complex values in Atom are represented with 200 OK and the Atom representation of a null value (<m:value m:null="true"/>)
> The exceptions are:
> - empty single entity is currently represented with 204 No Content
> - empty complex property is represented with 200 OK and a special NULL payload in JSON ({"odata.metadata": "http://host/service/$metadata#Edm.Null"})
> The first exception is because an atom:entry cannot be empty, the second is because we wanted(?) to represent complex type instances as JSON objects without a {"value:...} wrapper and thus need a special representation of an "unwrapped null value".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira