I hope to add a blog entry later this weekend on my experiences with ReSTian Rails at Snakes, Gems & Coffee.

You could do a GET of the image resource followed by a PUT of the updated image resource, as you describe.

Or you could define a separate associated resource for the image orientation and do a GET and PUT of that orientation resource.

I still havent found anyone address my concerns about “acting” on resources. If a REST service returns a resource, then from what I can make out from all I’ve read, using a web service like XML-RPC/SOAP would be used to perform an action on that resource.

Say, for example, I GET an image from a REST service. I want to rotate that image by 90 degrees and then PUT it back. The Rotating part cannot be accomidated by REST? Is that correct? Is the PUT transfering the modified Resource, or am I passing a series of actions to be performed upon that Resource? Do I GET the image, rotate the image on the client, then PUT the image back? Or do I PUT a series of transformations to be performed on that resource?

Each explanation I’ve seen for REST treats PUT as an SQL “update”, so in that sense, the second method is suggested (I only need to PUT a series of actions to perform) and is obviously a lot more light weight (I’m only passing the changes needed to be performed, not a copy of the updated resource). However, this means that each resource must be “aware” of the different transformations that can be made to it…

I’d appreciate your thoughts!

Oh, and I too would like to see a book from you guys!

Certainly we need a few good practical books on REST/HTTP to ship.

At least one of those fine books should cover the fundamental principles of Web-centric development, the way Gamma et al did for C++ Patterns, Fowler did for Refactoring, or Norvig/Graham did for CLisp. Something that nails it.

I nominate the lesscode.org team! Seriously, this is a great opportunity. There’s an unserved demand for exactly such a book, and you and your colleagues are uniquely and especially qualified to fill it.

Start tomorrow, offer a closed beta for pre-orders, release it as a DRM-free PDF eBook, charge $20 for rights to updates for a year or two, and I’m there!

I’m not kidding. What would it take to convince you? 50 pre-order pledges right here in the comments? 100? If you issue the challenge, I bet you’d get them. #1 right here.

I think you could even make money with this. 37signal’s eBook Getting Real brought in $33,000 in the first 24 hours.

If you put out the first definitive book on REST, that’s a strong preemptive move against The PR Problem.

Hopefully it doesn’t suck too much :-)

Hype could be a problem for REST if the “industry” gets on board with
it as a commmercial factor that requires ticking off rather than some
dorky engineering stuff – “Do they have REST? Check.”

How do we fight this? Replacing SOA or WS by REST in the press and in the vocabulary of analysts isn’t going to solve anything. In fact, if REST were ever to spin out of control in a way resembling Web Services or SOA, I’d consider going back to pouring concrete (how’s that for less code).

Our role will need to extend to that of vigilante should REST make serious in-roads with mainstream/commercial business IT. So while we’re oooing and awwing over Fielding’s profile in Time, we ought to make sure we’re calling bullshit when they get it all wrong, make outrageous promises, or otherwise misrepresent core concepts.

So I suggest we call phase one The PR Problem. That is, we confuse the shit out of everyone for a time with stuff like WS-Crossroads. Here we have Tim handing out props while at the same time being extremely critical. This will seem really weird to people used to the current Vendor / Standards Organization / Analyst / Press configuration because those guys all follow the same talking points and don’t often challenge each other. People will mistake the types of constructive conversations Tim and Daryl are having for weakness and that’s The PR Problem. But that’s okay, it’s phase one.