JSON-based architecture, how best to sync front and back

Question

Looking at using JSON for a new system based on REST.net, it looks great, but there is one thing that hints at my understanding. What is the strategy for keeping JSON on both sides of the application in sync?

What do I mean if you do a GET for: www.mysite.com/item/12345. Then the .net side of the application goes into db, retrieves the element with the identifier 12345 and solves it to an object model object, which is then serialized to JSON and returned.

If you perform a POST at: www.mysite.com/item and submit -

{ "Id": "12346", "ItemName": "New Item", "ItemCost": 45 } 

Then the .net side of the application selects it, deserializes it to an Item object and then passes it to add it to db.

How can you synchronize both sides, your JS object model and serialization of the .net object model? Does it just need to be maintained manually or is there a smart way to provide a template for JSON based on the serialization of the .net model?

I'm just looking for best practices and what I did, and I don’t see how the client side knows that JSON will go to the server.

Answer 1

Personally, it was easier for me to "manage" these changes for the .NET environment. Not wanting to teach you how to suck eggs, but Javascript is a very loosely coupled language, it means that changes / functionality / properties can be added to the hoof, while in .NET it is much easier to test and stabilize your POCOs more rigidly.

One of the methods I've played with recently is to generate empty POCOs from my service when creating objects, manipulate as needed, and then return them to the service for saving, etc. It still doesn't allow this wild western feeling while working in Javascript, but at least DataContracts can match on a superficial level.