2

I've been toying with the SimplyRestfulRouting assembly that comes with the MvcContrib extras, and for the most part I really like that it quickly sets up my routes and leaves me with a good convention to follow in my controllers. However, I'm still trying to wrap my head around REST as it applies to rich internet applications and occasionally feel pigeon holed when I need to do something that falls outside the scope of those 8 or 9 default routes. [Edit: By "pigeon holed", I simply mean I feel like I'm dirtying up the application when I have to create a controller action that is outside the definition of the default "restful routes".]

I heard a comment from a REST proponent in which he stated his opinion that the MVC framework is inherently RESTful, and it got me thinking a bit more about what libraries like the MvcContrib SimplyRestfulRouting are actually buying me.

Not having read a lot about the concrete pricinples of REST, I'm looking for input as to what benefits might come from enforcing such a thing in the context of a forms-over-data, RIA. And with regards to AJAX, how does a RESTful architecture affect my client interaction?

It's likely I'm misunderstanding the use of REST in this context, and would appreciate some StackOverflow mojo to get my head on straight.

nkirkes
  • 2,605
  • 2
  • 20
  • 35

3 Answers3

2

The main benefit I can see in enforcing RESTful routes -- regardless of the framework used -- is consistency. You'll always be able to know how the API will work for any resource, which will in effect give you a self-documenting API.

It also provides a wonderful constraint while architecting the application. Rather than having an API with a blank slate that could get complicated very quickly, constraining the routes to the basics will give you guidance as to which resources you'll need to create.

For more of the basic principles surrounding REST, I'd recommend reading this thread.

Community
  • 1
  • 1
ern
  • 1,502
  • 13
  • 19
  • Didn't want to leave the question open, and all the answers were helpful. This particular post included a thread I found useful in furthering my understanding of REST. – nkirkes May 22 '09 at 15:05
1

Being RESTful is more than just having clean URLs.

At an architectural level, REST is about organizing your application functionality in terms of resources, and exposing a fixed and uniform set of CRUD operations on them (e.g. HTTP POST/GET/PUT/DELETE methods). This is known as Resource Oriented Architecture.

In contrast, with Service Oriented Architecture you typically organize application functionality in terms of processes or components, and expose non-uniform, application specific methods on them (e.g. via SOAP).

Note, you can have clean URLs but still end up following non-RESTful SOA design principles.

UPDATE: Sorry, didn't really answer the question, got hung up on use of "RESTful" terminology. If you're just talking about the benefits of clean URLs (REST/SOA argument aside), the typical argument is better SEO optimization and user-friendliness (user can better make sense of and modify URLs).

DSO
  • 9,183
  • 10
  • 49
  • 58
  • http verbs are not CRUD at all. See http://www.innoq.com/blog/st/2007/04/rest_is_not_crud.html – SerialSeb May 21 '09 at 13:42
  • "Being RESTful is more than just having clean URLs." That's the crux of my question. I'm starting to understand the architectural implications, but from the perspective of RIAs, and in my case with an MVC based web app, I'm questioning the benefits I should expect to gain from attempting a Restful approach. Perhaps the only benefits are what you list in your edit, which is just fine, since my business sponsors don't have a requirement to provide any other access points into the app besides the web UI. Hmmm, food for thought... – nkirkes May 21 '09 at 18:08
  • Perhaps a better question to further the conversation is "when do you stay true to REST, and when do you decide to switch to a SOAP based architecture?" Design time is likely the best place to make that decision, but if you're mid-stream and a requirement that you were previously unaware of sneaks in? – nkirkes May 21 '09 at 18:10
  • Well if mid-way through a new requirement means changing your core architecture, then you're indeed in a very very complex situation. That said, if there's a specific requirement on SOAP, obviously REST is not going to help very much. You'd have to reimplement a separate facade. – SerialSeb May 26 '09 at 20:00
1

the advantage is that if you have some adress and from that adress you getting something, then you can call that adress from anywhere you want in you code, and you will get exactly same thing :)

and in concrete example, if you have route that can return some html full with data(user control for example), then you can call it from ajax, from your desktop application or even from your web service...it is very powerfull because you WILL have some functionality repeated over your application...and because some html that you getting from that restful service giving you exactly one view with exactly one functionality, you can call it dynamically from dialog or from page or from your desktop application or from anywhere... and when you add to this that you can call this adress with parameters, exactly like some method, you can now see how powerfull this can be in creating dynamic pages and web sites/systems

hope this helps

Marko
  • 1,816
  • 21
  • 36