Today at work an engineer showed me a web app he wrote to configure some data in a database - this avoids account managers calling him up several times a week to enable this or disable that. Sure, sure, trivial - but nobody had time to actually write the thing. Anyway, my friend is brilliant (brain the size of a planet) and yet he was using POST in his HTML forms for a simple query. Why? Because he didn't know. And hey, he's 'posting' the request right? I convinced him to switch to GET because "Hey, people can bookmark the stuff. You know, put links to the current settings of that in an email, or a trouble ticket, or whatever." I didn't go into the evangalism - I didn't need to, he got it immediately. (The people here are bright. Really bright.)

One step closer to the righteous day when all Web Services are REST Services...

So what went wrong? Why was POST in there to begin with? I think it has to do with not caring - moving from having nothing but a SQL-Plus command line or a custom console app to a Web page is so much of a leap that the little things like GET .vs. POST aren't noticed. Also - and I think this is important - the name of POST just doesn't lead to good usage. Now if it had been named UPDATE, many more people would be put off and probably use GET right away.

Somewhere buried in here is an interesting session at the upcoming BEA conference on "XML Data Services" BEA eWorld 2004. This also does double duty to show just how crappy a user experience can be when Web pages are built by fancy dancy frameworks that launch windows with script and use session IDs in the URLs.

Excerpt of what caught my attention in this link:

Data Services in SOA is not merely about exposing underlying systems via Web Service APIs. It is often the case that business relevant information needs to be aggregated and composed from multiple such systems. Furthermore, information modeling principles are essential in order to facilitate the discovery, use, reuse and management of these information related services. In this session, we will introduce BEA's solution to tackling this challenge. This solution, XML Data Services (XDS), provides the basis for creating, delivering and managing model-based Data Services in SOA. XDS will be delivered as part of BEA's upcoming BEA WebLogic Liquid Data 8.2 release.

Woohoo! Thanks to MarkB for pointing this out:
ActiveMQ::REST

ActiveMQ implements a REST-ful API to messaging which allows any web capable device to publish or consume messages using a regular HTTP POST or GET.

(ActiveMQ is an open source, Apache 2.0 licenced Message Broker and JMS 1.1 implementation.)

I had done a servlet just like this (probably not nearly as professional) and posted it over on SourceForge http://sourceforge.net/projects/destiny. It's very gratifying to see someone else attempt the same thing. Next, I'd like to see SMTP and NNTP smoothed over and made transparent by some decent HTTP gateways - oh wait, isn't Google doing that?

I think this is pretty entertaining.
Design by Fire: Design Eye for the Usability Guy

Although not about Web architecture and messaging, still eye-opening with regard to how much room for creativity and innovation there still is in 'legacy' Web technologies.

Hey, guys, you're all pissing in a very small pot - chill out.

Middleware Matters Steve Vinoski - Given all the above, if I had to compete against Artix, I'd personally be embarrassed to issue a press release touting a mere gateway.

Middleware Matters (Comments) Zdenek Svoboda - You have architected a nice pluggable transport architecture. This is all nice, but in my opinion, kind of late.

Service Oriented Enterprise Jeff Schneider - Hmmm... they joined an industry group, had a diplomat visit and wrote a white paper. Iona - you kick ass!! Don't bother with those silly press releases about new products - those... well, those are just embarrassing.

(Although I did think Jeff's post was pretty funny...)

This article by Jon Udell Random access to Web audio is interesting to me because it talks about tunneling HTTP headers in a URI.

What's missing?

A Web server convention for accepting parameterized URLs like the ones Ari Luotonen proposed way back when.

I think this concept applies to more than just Accept-Range headers. I've found it a very useful concept for indicating preferred content-types (the Accept header). In a more extreme vein, indicating PUT or DELETE semantics when in a constrained browser environment may also be useful.

Many, many jobs ago I built out a system that does just this - using "do:" as a prefix and using the literal HTTP header name. For example:

• do:accept=text/xml to receive XML


• do:accept-language=fr_ca to receive Canadian 'French'


• do:method=put to use PUT semantics for replacing a resource

(In fact, the remnants are in an Apache XML project called Xang - a Web application framework with request dispatching, XML data sources, etc. etc...)

In Jon's example, something like do:range=bytes=15105006- could be used to specify a byte-range offset.

As for Jon's concern about using bytes where time would be more user friendly, HTTP defines 'bytes' but allows for application specific extensions. (see RFC 2616). We should define a range units of 'time' with a syntax of HH:MM:SS or something derived from the ISO8601 time format specification.

Good article. Go read now.

All Things Distributed: Web Services are not Distributed Objects

Web services are frequently described as the latest incarnation of distributed object technology. This misconception, perpetuated by people from both industry and academia, seriously limits broader acceptance of the true Web services architecture. Although the architects of many distributed and Internet systems have been vocal about the differences between Web services and distributed objects, dispelling the myth that they are closely related appears difficult.

Many believe that Web services is a distributed systems technology that relies on some form of distributed object technology. Unfortunately, this is not the only common misconception about Web services. In this article, I seek to clarify several widely held beliefs about the technology that are partially or completely wrong.

This sounds interesting. So many technologies, so little time...

WebFountain, the Long Version

WebFountain is a classic IBM solution to the search problem. Instead of focusing on the consumer market and serving hundreds of millions of users/searches a day, WebFountain is a platform - middleware, in essence - around which large corporate clients connect, query, and develop applications. It serves a tiny fraction of the queries Google does, but my, the queries it serves can be mighty interesting.

I wonder where this wound up... and whether this would beat out mod-pubsub (should it ever attempt to scale...)

Newswire - Collaborative real-time content delivery:

"Subscription information stored in Bloom Filters is aggregated such that simple forwarding decisions can be made anywhere in the network based on the location of the publication and the direction where possible subscriber are localed."

This is also very interesting... I wonder if mod-pubsub could build a similar system.

Astrolabe continuously computes summaries of the data in the system using on-the-fly aggregation. The aggregation mechanism is controlled by SQL queries, and can be understood as a type of data mining capability. For example, Astrolabe aggregation can be used to monitor the status of a set of servers scattered within the network, to locate a desired resource on the basis of its attribute values, or to compute a summary description of loads on critical network components. As this information changes, Astrolabe will automatically and rapidly recompute the associated aggregates and report the changes to applications that have registered their interest.

I usually don't dive into academic papers, but this looked interesting. Haven't read it fully...

In this paper we present Captain Cook, a service that
continuously monitors resources in the Internet, and allows
clients to locate resources using this information. Captain
Cook maintains a tree-based representation of all the collected
resource information. The leaves in the tree contain
directly measured resource information, while internal
nodes are generated using condensation functions that aggregate
information in child nodes. We present examples of
how such information may be used for cluster management,
application-level routing and placement of servers, and pervasive
computing. The nodes are automatically replicated,
updates being propagated using a novel hierarchical gossip
protocol. We analyze how well this protocol behaves, and
conclude that updates propagate quickly in spite of scale,
failed nodes, and message loss

Service Oriented Enterprise:

"Call me silly for not liking an operation called, "getLastStockPrice". Call me dumb for not being able to figure out the REST equivalent of the operation."

The REST equivalent would be 'get'. The trick is to preface it with 'stockPrice'. So stockprice.get() might be a procedural language example. Or maybe server.get("stock/amzn/price") or maybe resource("stock/amzn/price").get() or maybe ...

Call me simple, but I just noticed the similarity of names between RELAX NG and REST - two technologies that work well together. What next? REPOSE... RECLINE...

Here's a pretty decent working description of 'Service' - from Manageability:

Service in my definition is that software entity that is designed in isolation however provides near frictionless interoperability. It's a strange almost mythical combination of competing requirements, that is it is both isolated and interoperable.

How interesting - a DNS based system for discovering several URI based services associated with a telephone number ENUM

From ENUM.org :
... it is the mapping of a telephone number from the PSTN to Internet services -- telephone number in, URL out

From RFC 3761 :
The result of the ENUM query is a series of DNS NAPTR resource records [RFC2915] which can be used to contact a resource (e.g.URI) associated with that number.

Hey look - PayPal Announces ''PayPal Web Services''. Didn't see a mention of REST - but I'll sign up and find out more.

update - It doesn't look like there is any REST oriented direct HTTP access, only SOAP messages defined via WSDL.

This analysis of Amazon's RESTfulness is very good and somewhat eye-opening.
I think this shows two things - organizations can get real benefits from REST even with a partially 'conformant' system and that there is still a lot of room for education regarding what HTTP can do.
I have a feeling that the particular use case that Amazon's system was designed to support is not so much as full automation by any kind of client application but rather it is focused on specific rendering and XSLT style client usage. If an XSLT engine has a hard time integrating then the HTTP usage would be simplified to fit.

This is a facinating app that lets you peek into your neighbors political affiliation.
I'm sure it's a simple SQL query, but what is very instructive is that fields in each result are a link to another resource (just another query) and all this with no custom APIs required. This is very cool hypertext. It shows in very information dense way the simplicity and immediacy of a Resource Oriented Architecture (tm).

So, it seems like I missed it, but 'rss is a notification technology'. Seems
to be the consensus in the community, technical details notwithstanding. And
if the technology currently doesn't deliver, then it surely will evolve to
satisfy the need. Catch a wave and your sitting on top of the world.

"So what's RSS, you may ask? It's a technology that notifies you when a site
is updated, and allows you to read the updated content without viewing the
site itself. Think of it like a mailing list for web sites. More reading is
available on this site's RSS resource page."

(From mezzoblue)

This is great -

HTTP over SOAP!?!?!? Check out SOAP Resource Representation Header, a recent product of the XML Protocol Working Group. The idea is you stick a resource representation in a SOAP header. When I first read this, I checked the date to make sure it wasn’t April 1st.

(from ongoing).
I sarcastically suggested doing something like that a year ago - creating some WSDL that represented the messages in HTTP. Too bad I never got around to it...

Mark Nottingham says Asynchrony: There Is No Spoon. To which I reply - "There is only FORK".

I really really like this approach - "A final approach would be to give the client its own explicit address (http://me.example.org/), modelling it as a resource as well. In effect, it becomes both a server and client at the same time. This pushes asynchrony to the application itself, by surfacing the different parties as different resources; this gives a lot of flexibility and power to application designers, but requires the client to be reachable by the server; a difficult task when it’s mobile or behind a firewall."

The 'behind a firewall' scenario needs somebody to put a custom Apache server on the client, build an Apache 'rendezvous' message-forwarding server and punch a hole out from the client to the server.

And what's this WARM stuff? Very interesting... must read...

"I’ve said before, HTTP can already provide reliability and high performance, and as we see here, asynchrony. What are the differences between SOAP and HTTP, then?" - go get 'em Mark!