RESTfull concept suggests to use different http methods(get/post/put.delete) for CRUD operations with specific request params and responses. Also it suggests send only necessary info.(for ex. no need send entityAspect for RESTfull API).

Similar functionality exists in JayData. Will be great if Breeze will support this functionality too. It'll be usefull for big apps, for api which have to be shared to other clients and expand area of usage.

Also this functionality will add supporting DTO without writing own context provider for breeze.webapi .net framework because in this no need to use breeze.webapi .net. Generally users will develop asp.net web api and other RESTfull services in way they used. Users can use breeze.wabapi context in case when they need batch save(for ex. when synchronize offline storage with remote storage) without supporting of transactions and if they need batch saving with separate transactions you have to implement OData batch processing (http://www.odata.org/documentation/odata-v2-documentation/batch-processing/).

Contact me if you need details related to idea and implementation.

Thanks for addressing my case about supporting the CLR DateTimeOffset type in breeze (supported from v1.1.1).

Please look at this case for background information.

I have looked into how serialization of JsDate/DateTime/DateTimeOffset works in Breeze, and found a single shortage that defeats my idea of using DateTimeOffset on the server.

I believe that you will find my change suggestion reasonable.

* In breeze, Dates are serialized in ISO-8601 format ("yyyy-MM-dd\\THH:mm:ss.fffK") both by the breeze client and by JSON.NET configured by Breeze.WebAPI.
This is according to my expectations.

* When a DateTimeOffset is serialized by JSON.NET on the server, the timezone part of the DateTimeOffset is reflected in the ISO-8601 serialized date string. (example: 2013-15-05T15:51:21.123+02:00).
This is also according to my expectations.

* When a JavaScript Date contained in a breeze DataProperty of type "DateTimeOffset" is serializeed by the breeze client, the dates are always converted to UTC. (example: if I was sending the same date back to the server that was retrieved in the example above, it would have been changed to 2013-15-05T13:51:21.123+00:00, regardless of the timezone of the client device.

Breeze should make use of the timeZoneOffset part of JavaScript dates, and keep this when serializing on the client. The server would then be able to get both the date, time and timeZoneOffset sent by the client into the DateTimeOffset type on the server.

My change request is therefore:

A breeze DataProperty of type "DateTimeOffset" should be serialized persisting the TimeZoneOffset of the JavaScript date. The timeZoneOffset would then be the same once deserialized to "DateTimeOffset" on the server and also when written to a datetimeoffset field on the SQL Server.

Hoping for you to solve this. It is in my opinion the last missing link to be able to handle date/time/timezone offset 100% correctly.

There are a few use cases where an entity instance needs to be sent to the server to an MVC API controller (for example for async server side validation); to do this, it is necessary to obtain an unwrapped version of the instance (plain JSON) that contains no internal properties such as entityAspect and uses properties instead of observables (ko.mapping.toJS is not suitable because of the former). Also, because the client configuration allows for a different naming convention, the method should be able to translate the names back to the naming convention originally used by the server.

Such a method already exists inside the EntityManager, is called "unwrapEntities" although it is private; so the suggestion is only moving it to the public interface of the EntityManager.

More details on this suggestion can be found in http://stackoverflow.com/questions/16202485/breeze-js-how-to-transform-a-breeze-entity-to-a-plain-json-object.

It would be nice to filter on the properties of 1-n related enities. [Even if it is a collection of entites and not a single (1-1 related) entity.]

With my suggestion it would be possible to execute the following queries:

•find all movies starring a particular actor
•find all orders where at least one of the order-lines is for a particular product
•find all orders where every order-line has a value greater than $400
•find all movies tagged 'quirky' - where Tags is a multi-valued property.
•find all movies with a least one actor tagged as a favorite

It would be great having these OData v3 ANY/ALL filter operators.

I have tested Breeze using ASP.NET WepAPI and the server OData endpoint already supports ANY/ALL filter operator.

Please implement at least on remote queries!

p.s.: JayData already supports them under the name .some() and .every()