Comments on Functional Form: REST: From theory to practice

Good introduction to REST. I happened to write one...

2008-11-26T09:40:00.000-08:00

Good introduction to REST. I happened to write one a few months ago on my dev blog. Cheers!

Mark, one big benefit lies in the integration.I've...

2008-11-25T23:07:00.000-08:00

Mark, one big benefit lies in the integration.
I've been doing REST services for nearly a year, and integration across platforms/frameworks is almost trivial in comparison with the SOA alternatives. One time we had someone from a different project which we were consuming come by, give us a URL and an hour later we were done.

I still don't understand what this buys you. So ma...

2008-03-12T10:26:00.000-07:00

I still don't understand what this buys you. So many books, blog posts, conference sessions... Compared to the adoption of OOP, this seems to me to have far more limited benefits (if any).

Most of what I've read about REST is about the philosophy and/or the implementation. Where's the beef?

///ark

excelent article. I have found making the update m...

2008-03-12T10:00:00.000-07:00

excelent article. I have found making the update method of the parent model(in this case 'shape') slightly more intelegent is often the solution Im most compfortable with. I hope to hear more of your thoughts on REST. You just earned yourself a subscriber.

That's really awesome especially the paragraph in ...

2008-01-22T03:17:00.000-08:00

That's really awesome especially the paragraph in which you build your case:

REST encourages a focus on resources. A resource is anything that can be named, and your system can have as many resources and corresponding names as you want. Conversely, there is a limited set of operations defined on those resources. Unlike objects in object-oriented programming languages, which support very diverse, rich interfaces, resources in a RESTful system are relatively uniform. So how can a sophisticated API be developed if REST requires a fixed and limited number of operations that resources can support? The answer: add more resources!

But honestly, I am not to expriment with some toy example and have to provide a REST interface to an earlier version of the application build on Rails. And if you try to be pure "RESTy RESTy" then you would have to face an exponential rise in the number of controllers and URL patterns.

However, Nice description! I learned a lot!

Regards,
Mohsin

I found this article helpful. One of the things a...

2007-12-25T00:34:00.000-08:00

I found this article helpful. One of the things about RESTful applications that always felt awkward was how to go beyond controllers that fronted a model object. I thought the examples in this post made sense as concrete examples of where you would want to create "subcontrollers" that provide an extended API and additionally functionality for a single model.

"REST encourages a focus on resources. A resource ...

2007-10-26T10:27:00.000-07:00

"REST encourages a focus on resources. A resource is anything that can be named, and your system can have as many resources and corresponding names as you want. Conversely, there is a limited set of operations defined on those resources. Unlike objects in object-oriented programming languages, which support very diverse, rich interfaces, resources in a RESTful system are relatively uniform. So how can a sophisticated API be developed if REST requires a fixed and limited number of operations that resources can support? The answer: add more resources!"

Does this actually make sense to you? How does the development of a sophisticated API have anything to do with the operations that REST supports? Are you suggesting that there is some mapping of objects in an API developed in an object-oriented language to REST resources? Do you write things just to amuse yourself?

I got a clearer picture of how to use REST with Ra...

2007-06-28T21:11:00.000-07:00

I got a clearer picture of how to use REST with Rails from that article than anything I've read so far. Thanks!