How can we improve Breeze.js?

RESTfull conception support

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 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 (

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

214 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Alex shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Brahma Acharya commented  ·   ·  Flag as inappropriate

    Yes indeed there are ways to intercept the save change method. Without that Breeze would be dead, isn't it?
    You can override the SaveChangesCore method of EFContextProvider and do stuff that you wish in that method.

    We have a multi-tiered architecture and we have successfully used Breeze in conjunction with the Web API layer. The Web API layer has no reference to EF or access to any Data access components. Heck we even have web models (DTOs) which are completely separate from our entity models. We use Automapper for mapping between entities. No matter what the folks say, in an Enterprise level application, I would never ever expose my entire core entity model to anyone outside. Period. It just gives away way too much information (some of which might be your USP).

    I also believe Breeze should focus on the client side and make things easier (like creating Metadata, using proper REST convention for updates (rather than just one method) etc.). Having said that, Breeze makes so much easier for client side data management. It has reduced the client side complexity by orders of magnitude. And if you are planning for a SPA, not having something like Breeze doesn't make much sense.


  • Patrick commented  ·   ·  Flag as inappropriate

    Here is a particular use case where this would be beneficial (for me at least : ))

    Assume that I have a web app that is using the Unit of Work and repository pattern. I want to define a specific save path when creating a new user (or requesting a user) so that certain tables that are not exposed to the client (specifically security information that resides on the server side only) have records created to allow the client to have a temporary user login security file created.

    (There may already be something to provide this by intercepting the saveChanges, but if there is I have not seen it / been able to do it with a unit of work YET)

    If I request a new user and call save changes, I am not able to intercept the new user to create it's temporary user security file. So far the only method I have found for this is to call save changes and then make an AJAX request to the server to create the security file, but that AJAX isn't a very secure / reliable way to request creation of a security file.

  • Dmitry commented  ·   ·  Flag as inappropriate

    This is really needed feature. It would be good to have this feature, I will definitely select breeze next time if this feature will be implemented.

  • Konstantin Pozdniakov commented  ·   ·  Flag as inappropriate

    Current implementation of breeze web api is great buttheart in real life projects. With current approach it's very hard to create even middle sized applications.
    Full support for the REST will be very helpfull.

  • John commented  ·   ·  Flag as inappropriate

    This is really needed feature, it will make life of developer much more easier!

  • Igor Yastrebov commented  ·   ·  Flag as inappropriate

    I think the idea looks very attractive.
    Default way of Breeze - to replicate heavy ORM between client and server looks suspicious - Internet channel could kill performance; or why should client ORM restricts my network interaction?
    Idea with full REST support looks if not a required but logical in terms of follow well-known standard. Why to invent the wheel?

  • Alex commented  ·   ·  Flag as inappropriate

    Hello John,

    I agree with you that create one http method for all CRUD operations for web api is simplest way. But it's not correct in case if developer want to create real RESTfull service which is shared for some audience and used in own app.

    About transactions.. I think that creating and commiting of transaction it's not RESTfull approach. So I'll agree with persons from this discussion that one RESTfull request is corresponding to one transaction.
    "In your request, you seem to be saying that the developer could use a REST API for saving a single entity, and a batch API (WebApi or OData batch) for saving all changes at once. This seems like the road to partial saves and all their problems." - not quite.

    Imagine that our domain model consists from three entities: Category, Product, Price. Category can have many products. Product have Category and one or more Prices.

    Let's imagine that we've created API for own usage and for some community:

    GET: http://someurl/api/categories/1
    POST: http://someurl/api/categories
    paramns: {name: 'category'}
    PUT: http://someurl/api/categories/1

    GET: http://someurl/api/products/1
    params: {name: 'product', prices:[{id:1, value: 100}, {id: 2, value: 200}]}

    Now we want create own app on base of this api and using breezejs. For now it's impossible.. For now breezejs will send every request as post method.

    Let's look at way that I'm suggesting.

    1) a) User filled form for creating of category and clicked save. Breeze.js should check how many entities in unchanged state. If only one entity is in affected then breezejs have to send request with with post http method and data corresponding only to entity(without entity aspect or any additional info). Identity information should be updated from data which will be returned from request.
    b) User want delete category. Breeze check the same condition and send request with DELETE http method. The same for update(put method)
    2) User filled form for creating of products. Added two price entities to product entity in this form. Business rule is that manipulation with product and prices is one business transaction. Breezejs start checking count of unchanged entities and will find that there are three entities in 'added' state.
    Breezejs must decide is it batch commit or it's one business transaction. In this case you have to add possibility for developer to mark manipulations with some entities as one business transaction(show somehow for breezejs that manipulations with product and prices is one business transaction with product entity in role of parent)
    In this case breezejs will determine that all affected entities is one business transaction, find root(parent) object and create post data(for ex {name: 'product', prices:[{id:1, value: 100}, {id: 2, value: 200}]}). Then send one request with POST http method for creation. Identity information should be updated from data which will be returned from request.
    The same logic for update/delete but with different params and http methods
    3) Breezejs found that all affected entities are different business transaction. In this case breezejs can use existing functionality for batch saving in web api or odata depending on saveoptions.
    In this situation we must add to existing API(for customers or products) supporting for one additional http method for batch saving. I think batch save will be used only in synchronizing of offline and online storages or in difficult requirements for app.

    So if breezejs will be implemented in that way then developers will be able to create real RESTfull api, web app based on created api with breezejs and breezejs will use batch saving if it has need. And it's very neccesary to mark that developer have just to mark somehow that some manipulations with multiple entities should be handled as one transaction(it should be implemented) and breezejs will resolve other difficult situations.

    I'm not arguing that it's not simple logic but if breezejs will support this then I think you won't have competitors :).

  • AdminAdmin (Product Manager, Breeze.js) commented  ·   ·  Flag as inappropriate

    The reason we create a single POST for saves with WebApi is that it is by far the easiest and most compact way to send a complete bundle of entities to the server for the purpose of a save. However, nothing in Breeze is tied down to this. In fact, the Breeze OData adapter does exactly what you suggests, except that in order to accomplish it we have to create a multipart-mime message that internally contains a collection of put/patch and delete requests. The multipart-mime is necessary for transactional support. We do it this way because this is what the OData spec specifies.

    In your request, you seem to be saying that the developer could use a REST API for saving a single entity, and a batch API (WebApi or OData batch) for saving all changes at once. This seems like the road to partial saves and all their problems.

    I like the idea of supporting REST urls. Our WebApi implementation supports GET in a RESTful manner (e.g. /breeze/northwind/Customers), and we could add support for the getting a single customer via /breeze/northwind/Customer/4321.

    Updates are another matter. The answers to this SO question about REST transactions imply that you should treat a “transaction” as its own resource. However, the answers disagree in the specifics. Some suggest that the transaction should first be created, then the resources added to it in separate requests, then committed in a final request. Painful.

    We already give SaveChanges its own URL, to which we POST, which appropriately captures the non-idempotent semantics of the save.

Feedback and Knowledge Base