Web Things, by Mark Baker

Eeek, the Hiptop is finally in Canada! Decisions, decisions …
(link) [del.icio.us/distobj]

Congrats, Sir Timbl.
(link) [del.icio.us/distobj]

Yah, ditto. I wonder though, why anyone doesn’t seem to be asking the meta question; who put this Senator up to it?
(link) [del.icio.us/distobj]

Welcome James! Subscribed.
(link) [del.icio.us/distobj]

Paper Airplane is a Mozilla plugin that empowers people to easily create collaborative communities, known as Paper Airplane Groups, without setting up servers or spending money. It does this by integrating a web server into the browser itself, including t
(link) [del.icio.us/distobj]

Now, that’s cute.

I’ll get right to the point. He writes;

However, in the asynchronous case, imagine your Web Service is just like a letterbox. Letters happily fit into the letterbox and get processed by the back-end (i.e. you), but the 42″ plasma screen TV you ordered doesn’t fit into the letterbox – it doesn’t match the physical dimensions (as per its “schema”). This seems RESTful, no?

Absolutely.

The fact is that regular Web Services have a far more uniform interface than the REST style. I’ve laid down the challenge before, but you can’t get much more uniform than one (imaginary) verb, can you?

That’s really good to hear you say that Web services have uniform semantics. But it’s impossible for them to be more uniform than REST, because REST prescribes uniform interface semantics by definition. That verb you talk about – “processThis” – if it is indeed uniform, then it has semantics that are, for the purposes of this discussion, identical to HTTP POST. And you can build a perfectly RESTful system with just that one verb, and it would be accurately characterized as loosely coupled and based on document exchange. In fact, I just built one a couple of weeks ago like that for pumping three channels of seismographic data from a digitizer to a communications controller. It’s just that in my experience, for most applications, you can build a better RESTful system with additional verbs, in particular GET. For example, if there were any need to have my comms controller initiate the request for data, I’d use GET.

The other approach to requesting data is to, for example, submitting documents which describe query terms or templates to services which process them and return the results. And that also has its place in RESTful systems, including ones I’ve developed. But when you don’t have to query, e.g. when the endpoint identifier for the service/resource to which you POST that document identifies something stateful, then GET is perfect for retrieving that state (such as the aforementioned seismic data). And of course, URIs makes the perfect endpoint identifier because they’re easily identified and contain all the information you need to grab the data (at least the good ones do 8-), without needing to know how to do a query on them.

Anyhow, this discussion is super-duper encouraging from my POV. We’ve come a long way from early Web Services Architecture WG meetings where folks were claiming things like “GET, PUT, and POST are only good for browsers”, or “REST requires humans”. A long way, indeed.

s/Web services/Web/g
(link) [del.icio.us/distobj]

My one year contract with Nanometrics wraps up shortly, so I’m out looking for new and interesting things to work on. I’m particularly interested in any large scale (aka Internet scale) data integration projects. Any vertical would be fine too, though I’m most experienced with telecom and wireless. I’m also happy to work either with the companies that have the integration problems, or with an ISV developing software that targets those companies.

Getting back into standards work would be fun too.

My resume is available; I’ll be updating it later.

Robert sent me a great email that deserves to be on the Web. He doesn’t have a weblog, but gave me permission to post it here.

Might be of interest to you, if you haven't seen it already. Came across
this justification for constrained interfaces and unified namespaces...it
ties the argument to economics and the "Wealth of Nations" (Adam Smith).

Reiser File System v4 ( http://www.namesys.com/v4/v4.html )

"The expressive power of an information system is proportional not to the
number of objects that get implemented for it, but instead is proportional
to the number of possible effective interactions between objects in it.
(Reiser's Law Of Information Economics)

This is similar to Adam Smith's observation that the wealth of nations is
determined not by the number of their inhabitants, but by how well connected
they are to each other. He traced the development of civilization throughout
history, and found a consistent correlation between connectivity via roads
and waterways, and wealth. He also found a correlation between
specialization and wealth, and suggested that greater trade connectivity
makes greater specialization economically viable.

You can think of namespaces as forming the roads and waterways that connect
the components of an operating system. The cost of these connecting
namespaces is influenced by the number of interfaces that they must know how
to connect to. That cost is, if they are not clever to avoid it, N times N,
where N is the number of interfaces, since they must write code that knows
how to connect every kind to every kind.

One very important way to reduce the cost of fully connective namespaces is
to teach all the objects how to use the same interface, so that the
namespace can connect them without adding any code to the namespace. Very
commonly, objects with different interfaces are segregated into different
namespaces.

If you have two namespaces, one with N objects, and another with M objects,
the expressive power of the objects they connect is proportional to (N times
N) plus (M times M), which is less than (N plus M) times (N plus M). Try it
on a calculator for some arbitrary N and M. Usually the cost of inventing
the namespaces is much less than the cost of the users creating all the
objects. This is what makes namespaces so exciting to work with: you can
have an enormous impact on the productivity of the whole system just by
being a bit fanatical in insisting on simplicity and consistency in a few
areas."

More REST promotion from the master storyteller. “[…] I fear the most common noise in integration will continue to be the sound of crisp dollar bills heading towards the source of a strong flushing sound.” – classic
(link) [del.icio.us/distobj]