1
votes

For a team of pure UI developers, without any idea about how oData service is implemented (a UI team without any dotNet knowledge/experience):

How can we make sure that the backend oData service layer will work fine with our BreezeJs frontend/UI code?

Is it important for BreezeJs javascript coders to have backend odata implementation knowledge?

Is there a way to validate/certify that a given URL/odata service point can work fine with BreezeJs?

The reason I ask these questions is: With our backend oData service implementation, we find oData url/services accepting POST method for update and delete operation. This is, in my opinion, incorrect from REST conventions.

Our oData url/services also accepts some special headers like X-HTTP-method with values like 'PUT', 'MERGE', etc.

That is why I ask: should breezeJS coders have odata backend implementation knowledge?

Our edit/save operations are not getting sync'd with the backend by BreezeJs. However, our read operations are working fine.

Please note: we use AngularJS along with BreezeJS. We want to use the databinding between AngularJS and BreezeJS entityManager for all sync'ing.

2

2 Answers

3
votes

The other answer is uninformed and incorrect. Breeze follows the conventions you tell it to.

Breeze is highly configurable to use whatever back end technology you choose. If you choose to follow RESTful conventions when naming your service endpoints then have a quick helper service on the client to construct those end points however you wish. I do it all the time. If you want to perform a checklist on your api services on whether they follow rest conventions by all means let the backend team do that.

You do have to know what parameters your services accept and the manner that they are accepted.

For the record, PUT and DELETE are not currently in the Html 5 spec as they are inconsistent. Using POSTs for adds and deletes is more secure and browser compliant.

0
votes

This is a common problem when 2 teams, one pure front, one pure back, are working on the same project.

If you use REST, you adhere to conventions so that Fronters/Backers knows that they speak a common langage.

If you use SOAP, you can define an XML file that act as a contract between the two worlds.

BreezeJS do not follow REST conventions, neither adhere to a contract, and following the docs might not be enough. So the answer is : yes, you have to know the backend implementation, and add robust integration tests to ensure that communication happens with no surprise.