Overnight this new term and meme has taken hold. Would that I were not familiar precisely with that that it implies.
It's enterprisey!Update:
Bill de hÓra writes in lesscode that the term now has among other things, a wikipedia entry, and a wonderfully animated architectural illustration with its own theme music.
Da-da-da-da-dadadadada! It's enterprisey!
I don't think I've seen these before. Paul James has a number of useful REST articles on his site.
I believe heavily in developing web applications using the KISS principles of "less is more".
Ethan Fremen writes in a lesscode comment...
The main way in which the additional verbs are really helpful in an application is whenever you want to manipulate multiple resources at once. Of course, in most cases where you’re doing that, you’re using even more of those ‘useless’ verbs, like MKCOL and PROPFIND etc.I don't think the comparison with an object-oriented programming language is helpful. Classes with only getters and setters are brittle in their context (very small amount of state that changes often, very closely located to collaborating objects within a single OS process, one or a few developers working together modify most of those classes, short release cycles).To me it’s like you’re arguing that the only methods anyone ever needs on a class are gettr and settr methods.
On the other hand with a distributed system it may be that the more methods in a system the more brittle in that context (very large amount of state that does not change often, very remotely collaborating systems across multiple network boundaries, many developers who know little if anything of each other, long release cycles)
A mechanism to "manipulate multiple resources at once" in the latter, distributed HTTP context may be to construct a resource that represents the collection of resources and then manipulate *that* resource using the smaller number of verbs.
The hurdle I've mostly climbed over to the level I currently understand REST, HTTP, URIs, Atom, etc. is that this is not an object system. This is an application protocol (and architecture, formats, etc.) for distant collaboration. The challenge is to understand what are the conceptual pieces in this system and how to map ones needs into this system.
Most of the heavy computational lifting of those resources *does* take place in object systems (or functional or...) where there is a rich processing vocabulary. The distributed part is just about moving representations around in a coordinated fashion to enable the heavy compuational lifting at the appropriate time and place. The architecture for one is most likely not going to serve the characteristics of the other. The more they are considered distinct the better.
That said, I cannot clearly articulate when to create a new method except that the resistence to adopting that new method will be great so the time spent thinking about how to use the existing methods will more likely be the time well spent.
My second articulation would be to suggest that if you want to create a new method or two, then probably so do I and so do several others reading this. Before long we would be drowing in a sea of new methods. There may be a Cambrian Explosion of new collaborative techniques if we focus on how better to combine the pieces we already have. Inventing another nucleotide should be a very high bar.
Update:
In another lesscode comment Paul James confirms this approach...
You don’t need new verbs to manipulate multiple resources at once, you just need another resource that represents all the resources you want to manipulate together and to then manipulate that with your existing verbs.
Good news for Java programmers seeking the simplest SOAP stack that could possibly work...
I am back implementing Alpine. This has no dynamic redeploy, no ease of use features, no Java1.4 support, no annotations. It's going to be so simple I will have it working before I fly off to the Alps for my ski trip
Steve Loughran writes about old binaries running (or not) on the next version of the Windows OS...
Now, making old apps work bad may finally create incentive for people to upgrade their office suite, but it will also break every single IT-written win32 app out there. That's serious, and going to become and ongoing issue, I suspect.If you want to take advantage of some specific OS, framework, library, or whatever... why would you not code the independent 80% part, well, independently? Writing software to your advantage is always about minimizing unnecessary dependencies.Fortunately, there is a workaround. Don't write Win32 binaries. Code in Java, Python, Ruby, Squeak or other interpreted language, and trust the runtime to be signed by the time vista ships. You sneak past the security problem without having to go to any effort, and you avoid being at all dependent upon the OS and any more delays.
Don Box has a couple of interesting posts on Microsoft's support for REST/HTTP. I don't know a whole lot about the products, but there's a long list.
He asks a good question: how would you dole out $100 in support of REST/HTTP within Microsoft. Since I cannot really address specifics within their current product line, I'd consider something like this:
Mark Baker writes...
Finally, the Web's getting its due.The most interesting vendor at the Infoworld Executive SOA Forum last week was ActiveGrid, a LAMP-based grid for various purposes.Ok, so who wants to break the news to the Grid folk? 8-)
Or was that the old Same place? Nevertheless...
I'd sure like to understand this claim and prediction from Eric Newcomer of Iona...
Now with customers deciding on the approach independently of technology, the roles are reversing. Customers are starting to tell vendors what kind of technology they need by creating their SOA based designs independently of their technology decisions.I see a lot of people putting blind faith in WS-* because the industry has told them to. But then the industry says WS-* interop is not ready and there is no standard for a full service bus, so you have to make an investment in a specific vendor.This strikes me as a very good trend, and appropriate for where we are in the evolution of the software industry, helping to lead us to a place of resolution for the current frustrations with enterprise software.
Same old story from what I can see. Anyone that wants an agile enterprise can get it using technology that is ten years old or more. There is *no* need to invest in WS-* or an ESB. I think an ESB could be a good investment in some cases but not because of any promise of a "standards-based platform".
Let's celebrate another post from Ralph Johnson...
I do not say that program development *should* be program transformation, I claim that it already is. Most work on software is after the first released version. The purpose of work on existing software is to transform it to the new version. Since almost all work on software is converting version N to version N+1, almost all work on software is program transformation...I do not claim that program transformations are easy, or that they can be automated, or even that we can always understand them. I am claiming that thinking of software development as program transformation is likely to lead to improvements in how we develop software.
