Here’s a few quotes from a presentation I found. I’ve replaced the
name of the technology with “____” below, and it’s the same technology in
each quote. What is it?
A key concept of the data web is this idea that the response to any ____
request will either contain data or another address at which to ask for
that data… If you get back data then you are done, if you get back
another address you make a request of that address, you will get back
either data or …
…
Using ____ we can consume and aggregate distributed
data without having to make new copies and without
complex multi-protocol clients.
…
An ____ data store is often depicted as a graph.
Here’s the offending
presentation.
And here’s some of my
past comments on this same technology. As I said there, those who don’t understand the Web, are doomed to reinvent it.
If contracts are
so important,
why are there
so many
of them, and why are their realizations
auto-generated and disposable
rather than
mature and commodity?
I’ve talked about both the
pluses and minuses
of
Amazon‘s
approach to Web Services
for some time now. Recently, I’ve heard that they’re in the process of
greatly expanding those services, which is great. But I think that before
they go too far with that, they should really dig a little deeper to learn
why it is exactly that their “RESTful” data retrieval services are getting the
uptake
they are.
I don’t think it’s controversial to claim that Amazon see the REST vs Web
services debate as primarily about
encodings;
either a message is encoded as a SOAP envelope, or it’s encoded as a URI, but in
both cases the abstract message – the information being conveyed – is identical.
I completely disagree, of course, and believe that there’s a very large
architectural difference between those two approaches; that in http URI form,
the URI isn’t the message, and instead, the surrounding HTTP message which
encapsulates that URI becomes the real message, while the URI itself is treated
as an opaque bag-o-bits. Through this encapsulation, GET becomes the operation.
What I just described I refer to as “accidentally RESTful”, and it’s
sur–
prisingly
common.
And while, for the simple data retrieval case, it is RESTful,
and a significant improvement over vanilla SOA, you’ll find that as you
add support for state-changing actions and just generally evolve that
application over time, you’re going to run into many of the same problems
you’d run into doing SOA.
Fair warning!
Update; oh, I suppose this is, in part, a response to
something Dare said
a couple of weeks back; those APIs he lists
ARE RESTful, at least with respect to using the uniform interface.
John McDowall on simplicity;
Making simplicity a goal in integration is key to success – it can be an aspirational goal i.e. integration may never but point and click but unless the goal is simplicity rather than solving many imaginary problems then the possibility to asymptotically approach it will never happen. So setting simplicity of solution is always the right goal.
Bingo. Now, what
architectural
constraints
can we adopt to induce
simplicity?
Anyone, anyone? 8-)
Drummond mints a corollary
to one of
Kim Cameron’s Laws of Identity;
The identifiers in a universal identifier metasystem MUST only reveal information identifying a user with the user’s consent.
… and follows it up with this bold claim;
So half the Web breaks this corollary before we’re even out of the starting gate. But it gets worse. Look at one of the current bulwarks of online identification: DNS. A standard requirement for most DNS name registries is accurate, current contact data for the registrant that is published publicly as “Whois” data. Although many registrars now offer proxy registration services to preserve registrant privacy and prevent spam, there’s no escaping that a major component of our current Internet identifier infrastructure breaks the First Corollary squarely in two.
Hmm, how exactly does Web/Internet/DNS breaks that corollary? I can’t see it.
Is it because of DNS (and if so, why the “it gets worse” comment)? DNS does
certainly require a small amount of information be made available, and though I’m
hardly a historian, the little I do know of the history of this data suggests that it
represents the minimum amount that a mature industry – which has had to balance the
needs of domain owners (anonymity) with those of the public at large (accountability)
over many years – has reached concensus on requiring. So I doubt that any competing
centralized solution would be able to reach widespread deployment without, in the
steady state, providing a similar amount of info about registrants.
Also, who says that there’s a direct correspondence between a DNS name
and the person who uses the email address? I don’t own gmail.com, nor yahoo.com,
yet have email addresses at both of those domains. Google and Yahoo, in
offering an email service, provide a degree of anonymity via proxy; if you
want to learn more about me there, you have to go through them, and I’m not
required to publish any info about myself there.
Hushmail‘s
probably the extreme case here, as they seem to exist to provide
as-anonymous-as-possible email services.
As you’d expect from a chair of the
XRI TC,
he then claims that
XRIs
don’t have this problem;
So can XRIs fix this problem? Yes. The first principle of XRI architecture is that XRIs are abstract – the association between an XRI and the real-world resource it represents is entirely under the control of its XRI authority (the person or organization registering the XRI, at any level of delegation). So nothing in an XRI need reveal anything about the authority’s identity or messaging address.
… which, as I’ve shown, is also the case with even DNS-bound URIs.
Paul Hoffman likes
this
anti-smoking ad.
I dunno, it doesn’t seem like it would be too effective to me. Sure,
it’s shocking, but why should shocking stop people smoking?
That said, it seems vastly superior to the hopeless Ontario Government
campaign titled – get this – Stupid
(with accompanying sucky tv ads). Uh huh. Disrespecting your target
audience; smooth move.
What about an ad showing a bunch of old white guys sitting in a boardroom,
schemeing about how to get teens hooked?
My favourite slide from a great presentation by Sam
(
link) [
del.icio.us/distobj]
The mailing list that I co-founded in ’96, returns. Discussions about the future of large scale, distributed, compositional software systems. And philosophy too.
(
link) [
del.icio.us/distobj]