These days I seem to mainly use this blog for once-a-year announcements of what I'm up to, which is useful as record for myself when I need to reflect.

So here's where I'm at, as 2015 begins..   ...

After filling up that other blog recently with 61 pages of content, one page a day, I was challenged by my ThoughtWorks colleague, Andy McWilliams, to help him get in more easily to my explanations of the Object Network applied to Augmented Reality and the Internet of Things, especially around how my approach differs and is better than other approaches.   ...

Right, let's get started with some basic conventions in the Object Network!

This part in the Object Network series will cover URLs, HTTP headers and some common JSON patterns.

Updated 23/1/12: I changed the URLs in the example to have one of each type.   ...

OK, I'm trying to take a Big Idea and make it as Simple As Possible to grasp.

If we link our JSON data together and use the same formats, then our mobile, browser and server apps can become much simpler - through clean, stable, common, shared, re-used code - and much more powerful - through clean, stable, common, shared, linked, cached data.

This is the second part in the Object Network series, which will guide you away from building isolated Web APIs to engaging in a linked-up data landscape.   ...

It's interesting to compare the current growth of Web APIs with the early growth of the Web itself. To save you jumping those links: the Web dramatically beats the APIs.

I believe that the most likely cause of such relatively slow growth (in what should be a booming ecosystem) is that each API forms a closed silo and cannot benefit from any network effects. Every API is different and there are no links between them. There usually aren't any links within a silo. You can't even use a given API without first consulting the documentation.

The Object Network is designed to fix this, with linked-up JSON in common formats. This will allow easier mashing, sharing and cacheing of data and allow client code to be shared and reused.   ...

The Web, in its purest form - declarative HTML and CSS documents, XML feeds - is mashable, linkable, sharable. It's easy to create documents that slot into the global Web and can be accessed on any device; accessed by just a simple link. Servers can easily scale through statelessness and cacheing.

Native Mobile Apps are fast and slick. They are intimate with the dynamic, interactive, tactile mobile user interface, intimate with the capabilities of the device and intimate with the domain of mobile: photos, locations, contacts, messages.

OTS is a simple, clean, powerful approach to delivering Mobile functionality and content that is designed to realise these benefits of both Native Apps and the Web.   ...

Like Subbu, I also have been sitting on a blog post about the Richardson Maturity Model. I have different reasons for feeling uncomfortable with this Model, however.

The following came out of a discussion on an internal list at ThoughtWorks, where a number of people were talking about how they aspired to reach the "Holy Grail" of REST Level 3, and still thought they were basically "doing REST" by addressing most of the uniform interface.

But, as indeed pointed out in that article, REST is only at Level 3.

However, fortunately, you can jump right to Level 3 without much effort.   ...

This post is a response to a question that came up on an internal ThoughtWorks list. The question was, in summary: "Is using JSON more RESTful than minting our own Media Types as required, given that using raw JSON means reading inside the content in order to know what type is being transferred?"

TL;DR: Yes, use a common Media Type and "switch" on the internal data type; create a new Media Type only when something generic and broad and new and useful settles out.

Seems controversial to you? Read on...   ...

Around the middle of February I completed a basic persistence and networking implementation for Fjord, then had to do other things for a month. Just recently I fixed Fjord to work with the latest version of the Node.js APIs.

Next project: I'm going to use Fjord in a Web Framework to be called "JSON-Mash".

I intend to show that JSON-Mash will be a great framework for rapidly building truly interoperable and truly scalable online and distributed functionality.

Here's how JSON-Mash will work.   ...

Say we want to integrate multiple applications which handle order processing. OK, that's got to be one of the dullest starts to a blog post. Never mind, bear with me...

So, we have applications on separate servers for handling and driving data such as orders, product descriptions and catalogues, stock lists, price lists, tracking, packing notes and delivery notes, invoices, payments, etc.

We may choose an SOA approach, of course. But let's say our sponsors have heard of this cheaper alternative: REST! Which to them means 'using Web technology to save money'.

Now .. suppose we push the time slider right back to before Mark Baker and the SOA -vs- REST Wars - or the 'SOAP -vs- REST Wars' as people naively called it. To when REST was simply (!) a description of the Web's architectural style...

What if we revisit the applicability of the Web, and its abstraction into REST, to the architecture of machine-to-machine distributed systems - to something like our order processing integration?

I think we'd quickly arrive at something that looks more like FOREST than, say, AtomPub...   ...

Since the day in 2006 that our dialogue took place with an imaginary eBay Architect, he has been promoted to imaginary Enterprise Architect in an investment bank! Convinced by the merits of REST, he took his enthusiasm for it into his new job and embarked on architecting a trading system using REST or ROA as an alternative to SOA.

Now, he hit upon a snag: he had a REST "bank server" generating bids on an instrument and POSTing them into that instrument's REST "market server". But then he had two copies of his bid! One held by the bank server on one URI, and the other in a "bid collection" held by the market server's instrument - on another URI.

He asked himself: "Which URI is the real one? Which host 'owns' the bid? Is the market's copy just a cache? If so, why does it have a new URI? Why doesn't the market host know the URI of the bank's original bid? Why can't servers become clients and just GET the data that their own data depends upon?" The server seemed to be dominating the conversation, not letting its 'client' server have a say in things.

Our worried Enterprise Architect noticed that such Service-Orientation permeated REST practice: there were "REST APIs" to Web sites, or "Web services" with a small 's'. Even AtomPub had a "service document"! Some patterns, like AtomPub, offered just simple read/write data services through the full HTTP method set. Some simply used such a read/write interface as a wrapper around more complex service functions.

He wondered: "Where's the Web in REST integration? The Web works great without PUT and DELETE: isn't using GET on its own RESTful enough?"

So, remembering something I said about "Symmetric REST", he contacted me again...   ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP.

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 9: Web Objects Ask, They Never Tell   ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP.

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 8: WS-Are-You-Sure (Security, Reliable Messaging and Transactions)   ...

Mobile Monday London met last night to discuss the Mobile Web and Widgets. It was an engaging and thought-provoking evening.

Your intrepid reporter was there and, in spite of the crashing of his sad, clunky old Windows Mobile Xperia X1, losing all his notes, he brings you this hot report from right out of his memory (somewhat steamed up by subsequent socialising, but reclarified by Google).

After that, I give an explanation of why I believe that Widgets are not the solution to what Mobile 2.0 needs...   ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP.

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 7: Business Conversations   ...

Since the announcement by IBM and Linden Lab that OpenSim can talk to Second Life, I've been thinking again about RESTful Virtual Reality.

I'm not the first, of course. Others have been motivated by the same goal: To bring the Web's scalability, linkability and interoperability into Virtual World platforms.

Ultimately, how to use the same techniques as the Web to link Virtual Worlds together into a single, massive 'Virtual Universe'.

Here's how I would architect the Universe Web...   ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP (GetSearchResults, GetItem, GetCategoryListings, etc).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 6: Content-Types and URIs   ...

Last night's Google London Open Source Jam (also here) was on the subject of the 'Web' (didn't they invent that? Oh no, that was Microsoft).

This event has been getting better and better each time I've attended. There were some very interesting lightning talks held together with a tight structure and plenty of chance to chat, drink cold Leffe and eat cold pizza. And nick [transatlantic translation: 'steal'] the Green & Black's chocolate.

An ideal Micro Conference...   ...

Web 2.0's definition includes seeing the Web as an application platform. Which means it is in competition with Java and .Net, and with SOA, for both local and widely distributed applications.

If the Web is going to be a platform, the skills you need to learn to program it are the core Web 2.0 technologies such as Ajax, JSON, Atom, Microformats and OpenID.

And Ruby. This language, that's capturing the hearts of many Web 2.0 programmers, is ideal for easing the transition from the Java and .Net platforms to the Web platform, as I will show.

Even if you're part of a big company that is generally immune to the latest trends, the marriage of Ruby and the Web-as-platform may be something to prepare for. It could even displace your SOA agenda...   ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP (GetSearchResults, GetItem, GetCategoryListings, etc).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 5: The Distributed Observer Pattern   ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP (GetSearchResults, GetItem, GetCategoryListings, etc).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 4: Inter-Enterprise REST Integration   ...

What do all the MAJOR Web 2.0 technologies of 2007 have in common?

Let me list them first:

    M.icroformats (including tags)
    A.jax (including Comet)
    J.SON (plus YAML)
    O.penID (plus SXIP, LID, Yadis)
    R.EST (including Atom, APP)

What these technologies have in common is that they're all lighter than their competitors:

  ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for a few of the many function calls that they make available via SOAP (GetSearchResults, GetItem, GetCategoryListings, etc).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 3: Business Functions   ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for one of the many function calls that they make available via SOAP (GetSearchResults).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 2: Setting Data   ...

In an exclusive nine-part dialogue with an imaginary eBay Architect, we present an accessible discussion of the REST vs. SOA issue.

Although eBay have what they call a 'REST' interface, it is, in fact, a STREST interface, and only works for one of the many function calls that they make available via SOAP (GetSearchResults).

In this dialogue series, I argue the case for eBay to adopt a truly REST approach to their integration API.

Part 1: Getting Data   ...

Don't write your interactive Web application in custom Javascript! The Web's Declarative nature needn't be broken just because you want two-way dynamic data instead of one-way documents on your site.

Instead, write Declaratively to generic Javascripts, plugins and browser features such as Hijax, hInclude, XForms, SVG, XBL, etc.   ...

Open Data .. has .. recently .. been.. all .. over .. the .. blog .. o .. sphere!

Openness is a classic Us-and-Them issue. Big, nasty Apple/MySpace/Flickr is trying to control what little me/SingleStatus/Zoomr can do with my/our own stuff.

Open Data vs. Closed; Open Source vs. Proprietary; P2P vs. DRM; privacy vs. surveillance. The battles between the freedom of the pioneer, the individual and the minority against the rules and stability of the establishment and the majority form the endless shape of human history.

Us beating Them is Hollywood's favourite subject on-screen - and ironically Them fighting Us Hollywood's favourite battle off-screen.

As an Us-and-Them issue, with Us less powerful than Them, it's also tempting to give up and to follow the crowd - to do what we're told, to not ask for or sieze the privacy and open data we feel entitled to.

However, at XTech 2006 recently, there was a set of talks on the subject with a more positive approach.   ...

It gives me great pleasure to announce the 2006 'What Now How' Awards for REST Protocols (or 'APIs') in the Read/Write Category.

All this year's awardees share the distinction of being truly worthy of the 'REST' label; these Read/Write Protocols are acknowledged here for their uncompromising adherence to the simple principles of the World Wide Web.   ...

Microformats are subversive: they not only challenge the approach of full-blown Semantic Web approaches, but even question fundamental Web 2.0 building blocks such as Web Feeds and Web APIs.

I recently attended XTech 2006, where there were a few talks related to Microformats.

After summarising these talks, I'll finish with my shocking revelations about the subversive nature of Microformats!   ...

The vast majority of supposedly 'REST' Web APIs are simply abusing HTTP to carry function calls. I call these APIs 'Service-Trampled REST', or STREST.

STREST APIs come with specific costs which could stifle the two-way data Web (Web2.0) if allowed to propagate unchecked. Although 'mashability' is a supposed benefit of the current proliferation of APIs, true interoperability and scalability can only be guaranteed by true REST interaction.

This is not an academic, purist or aesthetic stance, but one based on practical consequences, as I will explain.   ...

Distributing an application over a network isn't just a case of splitting it down a natural line and putting a network in-between. What works in-process simply doesn't work so well across the wire.

And just calling such an Internet version of application and process interfaces 'Web' Services doesn't mean it has anything at all to do with the Web, or that it in any way shares the Web's scalability, flexibility and robustness.

Indeed, I claim that you cannot distribute without also 'inverting'; you have to face what I call the 'Imperative-to-Declarative Inversion', if you really want a successful, scalable, distributed application.

Declarative Architectures such as REST (i.e. the Web, and now 'Web 2.0') dominate the broader Internet.   ...

There is something about the Internet that nurtures open data, and something about computers that nurtures closed. It is often necessary, but often painful, to make the jump from local, closed data to global, open data.   ...

Declarative Architectures focus on the What, not the How, of programming. The How has dominated the field - perhaps 80% of programming is done in the traditional Imperative style, where we tell the computer How to do a task in explicit steps.

I'd like to show in this blog how Declarative Architectures and technologies are not just an interesting sideshow to the main Imperative attraction, but a complete and powerful programming alternative in their own right - indeed, one which has already dominated certain fields.

Imagine being able to simply express What we want the computer to do - to give it constraints and rules - then let it work out for itself How to achieve our goals.

I believe that saying What, not How, will become the dominant paradigm in programming.   ...