Mest

Erik Johnson (via Stefan Tilkov) wonders what's so bad about the "process this" notion. Jim Webber, a coiner of Mest, spent time in his recent QCon talk on this idea before moving on to a nice exposition of HTTP hyperstuff.

I think I have a reasonable handle on what the HTTP methods generally mean. I've not applied them to a wide variety of situations, and I wonder sometimes where that line and whether some specific use is crossing it too far.

More than that though is I've been playing with XMPP a bit again. Where is that line between pushing HTTP too far and jumping over that line into XMPP for "Mest", ad hoc, "process this", I'm not counting on any of the benefits of HTTPness?

These lines are probably fairly blurry on close inspection, when the programmer does not have a clear set of constraints leaning one way (e.g. GET's benefits) or the other (e.g. presence/status). but I've certainly found running an XMPP server and connecting from various systems at least as easy as doing the same with an HTTP server. And XMPP (over HTTP) runs through firewalls, for better or worse.

Anyway... if you are interested in that "one method to process them all" then why not use XMPP for that, and leave HTTP for more specific duties? Or not. If you are in a Mest then are you saying you have no clear understanding of your resources and constraints and so HTTP POST *is* as good as anything?

Just noodling...

Relaxing

Making It Real

James Snell's story highlights the point I just made in the previous post. The conversation about SOA / WS-* / REST should move forward by experience reports not from vendors or implementors but from people developing real applications...

Those who are familiar with my history with IBM should know that I was once a *major* proponent of the WS-* approach. I was one of the original members of the IBM Emerging Technologies Toolkit team, I wrote so many articles on the subject during my first year with IBM that I was able to pay a down payment on my house without touching a dime of savings or regular paycheck, and I was involved in most of the internal efforts to design and prototype nearly all of the WS-* specifications. However, over the last two years I haven’t written a single line of code that has anything to do with WS-*. The reason for this change is simple: when I was working on WS-*, I never once worked on an application that solved a real business need. Everything I wrote back then were demos.

Now that I’m working for IBM’s WebAhead group, building and supporting applications that are being used by tens of thousands of my fellow IBMers, I haven’t come across a single use case where WS-* would be a suitable fit. In contrast, during that same period of time, I’ve implemented no fewer than 10 Atom Publishing Protocol implementations, have helped a number of IBM products implement Atom and Atompub support, published thousands of Atom feeds within the firewall, etc. In every application we’re working on, there is an obvious need to apply the fundamental principles of the REST architectural style. The applications I build today are fundamentally based on HTTP, XML, Atom, JSON and XHTML...

Are average developers and architects able to design ANY system correctly? I think if you look at the history of software development as a whole, you’d really have to stop and wonder about the answer to this question. The fundamental challenge comes down to this: developers get paid for coming up with solutions that work; doing so means learning just enough about a technology so address the immediate need so they can move on to the next line item in their list in order to meet the deadline; this will quite often mean that average developers and architects aren’t even going to bother designing and implementing solutions “correctly”; nor should we ever actually think that they will. The best we can do as tool providers is educate users better and provide excellent tooling that makes it easier to do the right thing. Most of the time the tool developers can’t even get it right tho.

RFC

Steve Vinoski puts out a request for comments, of sorts...

I personally know of nobody who has ditched REST for WS like this, but if you have, or if you know of someone who has, I’d love to hear the whole tale, so feel free to leave it in a comment.

Maybe the next SOA / WS-* / REST confab should be restricted to experience reports about building real applications.