There are several differences between the capabilities of an OData service and a Web Api service when exposed to Breeze. Most of these differences are simply the result of either the OData specification or the Microsoft ‘datajs’ JavaScript library for OData (which Breeze uses to provide OData support) not supporting certain capabilities.
These are NOT Breeze specific issues.
var query = EntityQuery.from("Customers")
.where("companyName", "startsWith", "C")
.select("orders");
var query = EntityQuery.from("Customers")
.where("companyName", "startsWith", "C")
.select("orders")
.expand("orders");
With OData, any change of the value of a server side computed field will not be available in Breeze after an update. If you need these values refreshed, you must requery.
With OData, no EntityManager ‘EntityChanged’ events will occur as a result of an update, because in effect the client side entity is not updated except to note that it’s entityState has been changed.
Note: OData Insert operations, handled by an HTTP POST, return the inserted entity. This is what allows Breeze to correctly reflect the transition from a temporary entity key to a permanent one after a save operation returns.
OData optimistic concurrency uses ETags, so you will not see changes to any optimistic concurrency properties if these are exposed on the client. Breeze makes use of the ETags and you will get optimistic concurrency checks, but as noted above, this information is not returned to the client as a change to any of the underlying optimistic concurrency properties.
Breeze’s WebApi implementation can add or remove an object from the save on the server via the use of the BeforeSave interceptors. These are not available in OData.
Breeze’s WebApi implementation does support a server side KeyGenerator. OData does not.
Breeze’s WebApi implementation does support the concept of a “Named Save”. OData does not.
OData does not support .NET enum types.