Last post Mar 09, 2012 06:58 AM by InterTed
Mar 03, 2012 07:37 PM|fernandoacorreia|LINK
I'm thrilled to see Microsoft working to make developing single-page applications a lot easier. I have been watching the videos, reading blog posts and going through the demos, trying to grasp it. There's some amazing, pretty powerful stuff there that makes
me want to start using it as soon as possible. But currently I have mixed feelings about the approach.
I love the decisions about using Knockout and History.js. Upshot.js seems very compelling as well, and so does ASP.NET Web API.
But I've been having a lot of trouble coming to terms with the notion that, at this moment in the evolution of the Web, Microsoft is promoting a non-RESTful way of working with HTTP services. At least that's what I understand so far.
Although it's said that ASP.NET Web API can be used to build both RESTful and non-RESTful web services, the single-page application story seems to be non-RESTful.
For instance, in the BigShelf demo, deleting a friend from the user profile won't generate a DELETE command to a resource such as /api/profile/1/friends/3 but a POST command to a generic, gateway URI /api/BigShelf/Submit with a payload which specifies
the operation code:
So it's clearly following the RPC style. Similarly, an update won't issue a MERGE or PATCH request to for instance /api/profile/1, but a POST to the same URI /api/BigShelf/Submit with
"Operation":2. And it won't use a HTTP standard such as If-match for concurrency control, but it will send the entire original entity on the request.
The sample server-side code also follows a RPC style, declaring methods with verbs such as GetFriends, InsertFriend, etc.; it seems to return entity instances, so it's not clear if they can be enriched with links to provide the paths for navigation
to their properties. The fact that the client receives a metadata which specifies the relationship between the .NET model classes seems to indicate otherwise; it seems links won't be used for discoverability, but the client will have to have direct knowledge
about the server-side object model.
I can see how this RPC style can enable rapid software development, and I'm sure it will be adopted by tens of thousands of developers. I'm just having difficulty understanding why at this point in time Microsoft is not leading them towards full
compliance with web standards including proper use of HTTP, resource representations and especially a uniform interface to web services.
So I'd like some feedback on these perceptions. Maybe there is a way to use
ASP.NET Single Page Application to work with RESTful hypermedia API. That would be great, although it would be even better if the demos would show that. From what I've seen so far, though, it seems REST is being fully ignored in the SPA feature. It's
also a little hard to understand why OData services are not being leveraged (or maybe even not supported?) with SPA.
Mar 04, 2012 05:45 PM|marcind|LINK
While I don't work directly on the team resposible for upshot/spa I believe the reason why operations are submitted in this RPC fashion is that Upshot supports operation batching, that is instead of sending a number of small requests one after the other
it will group them into a single batch/transaction.
There are a number of reasons to design a system this way:
Of course such requirements force you to diverge from pure ReST, but as you can see there are reasons to do so and ReST is not the only architectural style out there.
Having said that on the Web API side of things we do have functionality for wrapping multiple individual HTTP requests into a single request (think something similar t multi-part file uploads) which then get split up on the server and executed in turn. However,
that means you end up with a wire format that's quite similar to what upshot already uses, except with the additional overhead of all of the per-request headers rolled into the message as well.
But in general your's is valueable feedback and I'm sure we can make Upshot have a mode where it does not batch operations and sends everything in individual requests.
Mar 04, 2012 09:41 PM|fernandoacorreia|LINK
Hello Marcin, thank you for your reply.
It seems that the ability to batch resources in a single unit of work is what has influenced the design decision for RPC instead of REST.
Of course REST is not the only architectural style, but it has a lot going for it, especially for applications deployed on the Internet, because it embraces the way it works. I'd rather have my applications follow standards than having to tell API consumers
that operation 3 will delete a resource.
I'll try and learn more about this. I don't think it's just an issue of pragmatism vs purism; it seems it's possible to be at the same time pragmatic, supporting the batching and disconnected requirements, while at the same time following the RESTful style.
I think the unit-of-work scenario in many cases can be realized by applying a structured resource, i.e., a resource that contains structured data. For instance, an order with all its associate information would be a single resource.
Unit-of-work between distinct resources could be achieved by using multipart HTTP requests. I would think this approach would be more conformant to web standards, because it would use an established convention to issue batches of requests to a single URI
while at the same time still addressing each individual resource by its own URI.
Mar 09, 2012 06:58 AM|InterTed|LINK
I have to fully agree with Fernando on this one.
At least upshot.js should support full RESTful mode (including multi part stuff) because I don't want to develop and maintain an API for our own front end bits and one that my API only customers want to consume for their own apps. In the same way Facebook
and Twitter UIs consume exactly the same API's as the one I'm using when consuming their data from my app.
So make sure you offer a choice at least.