If the Design Patterns movement had been popular in the 1980’s, we wouldn’t even have C++ or Java; we would still be implementing Object-Oriented Classes in C with structs, and the argument would go that since programmers were forced to use C anyway, we should at least help them as much as possible. But the way to provide as much help as possible was not to train people to habitually implement Object-Oriented Classes when necessary; it was to develop languages like C++ and Java that had this pattern built in, so that programmers could concentrate on using OOP style instead of on implementing it.

Update: and an excellent follow-up by Mark addressing a response by Ralph Johnson (one of the Gang of Four).

When I found the link in my aggregator, I was expecting the worst, but the title is just gratuitously incendiary. The actual article is thoroughly reasonable. It asserts that learning better languages will make your day job an excercise in demoralization and then asks the question: if you’re a C#/Java developer in the trenches, how do you benefit from your broadened horizons?

There is lots of good discussion in the comments; don’t skip them. What there is not, unfortunately but unsurprisingly, is an easy solution.

If you’re like me, and I know I am, you’ve got about a hundred accounts to keep track of on various systems — systems on the Internet, systems running in various corporate data-centers accessible only via VPN. You’ve got a slew of credentials to manage and no ability to leverage all that information at once. You spend your day duplicating and copying information between these systems, like some sort of freaking acolyte — serving The System — when The System should be serving you.

Meanwhile a million Web 2.0 startups are blooming. All DIY’ing for attention-equals-users-equals-dollars. Many of those startups are trying to tap both the consumer market and the corporate one too. It ain’t easy though since consumer buzz or even adoption does not always lead to access to fat corporate accounts.

What would it mean to you if you could use your favorite set of Web Apps all day and never have to log in twice regardless of which life you were leading moment-by-moment? How much more effective would you be if for each application, all your information in that application was available at once instead of walled off in separate accounts?

What would it mean to a Web Application provider if it was able to paint that picture for you? Would you be more loyal to that brand? Would you induce your employer, your client, your scout troop to use/purchase that brand?

I think there is a way and if you’ll lend me a few more minutes of your precious attention I’ll spin it out.

Imagine

The prevailing identity model in information systems arose around the enterprise system deployment model. In an enterprise system deployment, substantially all of the users of the system are employees of the enterprise. The enterprise itself is not represented at all in the model since each system serves only one enterprise.

This identity model has been carried forward to Internet-based applications. Just about all Internet-based applications offer accounts. An account represents a contract between the service provider and an individual. As such, most Internet-based applications are modeled like one big enterprise. Web Applications that offer corporate contracts offer separate identity systems for each corporate entity. At the end of the day, each of these identity systems — the “consumer” space ones and the “corporate” ones are separate.

Now let’s imagine a future where all applications are Internet-based. It’s easy if you try. Further, lets imagine that the market for some key Web Applications has settled down and consolidated a bit. So instead of a hundred wiki providers maybe there are three very popular ones. Kind of the way things were five years ago on the desktop with Word/Excel/Powerpoint/Outlook but this time, Internet-based.

Now let’s take a look at a knowledge worker, “Jessica” using say a wiki service, “WikiGood”. In the morning Jessica spends a few minutes in WikiGood writing out her plans for the day and reviewing progress against yesterday’s. Jessica has consulting engagements with two clients, “BigBoxCorp” and “NowYouSeeIt” but she’s in luck — both of her clients have standardized on the WikiGood service and use it heavily for day-to-day operations. As the day progresses she will interact with both of these corporate wikis as well.

In the first usage instance, Jessica is working on her own behalf, and wishes to keep the content private. What happens when she decides to do some work for BigBoxCorp? Well she logs out of WikiGood and logs back in with the identity assigned to her by BigBoxCorp. No problem. Other than the fact that she has two sets of credentials for WikiGood, oh snap, hang on — three sets of credentials because she’ll also be doing work for NowYouSeeIt.

There is a proliferation of accounts and credentials, but that’s not the worst of it. The deeper problem is that each WikiGood account is an island — even though all of the accounts are Jessica’s. Her preferences, her usage history, in short, everything associated with her in the system is divided, walled off, in three separate spaces. When Jessica is logged in under her NowYouSeeIt account and issues a search for instance, she will not find results for any of her personal wiki pages since the system knows her only (at the moment) as jessica@nowyouseeit. What if WikiGood is using Google AdWords to present Jessica with targeted advertisement? Is she a different Jessica when she’s logged in to her personal account than she is when she is logged in to her BigBoxCorp account? Google would like to think not.

Relate this scenario (personal account, and two corporate accounts) to other applications you use every day like email, contact list, calendaring, meeting scheduling, blogging, idea management, note taking, project management, personal task list, IM, VOIP, search. As these applications learn more about you, and you invest more time creating information in each application it rapidly becomes unacceptable to switch systems or even to switch accounts on the same system.

People increasingly expect and need the systems they use to learn more about them and to provide enhanced service based on that knowledge. Systems architected ignorant of the multiplicity of lives people lead force people to waste time repeating themselves (to systems) and copying information (between systems). More generally users of these systems fail to realize the full potential benefit of the knowledge they have shared. This is not a new problem, but it is certainly seems like a more pronounced missed opportunity in the age of Internet-based applications.

The situation is problematic. Users of systems would like to minimize the proliferation of credentials they must carry. Also they would benefit greatly from the ability to connect their accounts in a single system in such a way that they have visibility across all their content at once, and in such a way that they wouldn’t have to spend time re-entering profile, preference and other information into each account. Corporations seek these same benefits for their workers because it makes the workers, and hence the corporation, more efficient. On the other hand, corporations still have a desire to limit access to information (e.g. to employees only), and to monitor employees activities (shudder) if not for pure evil purposes, for regulatory ones.

But what of the service provider’s interests? WikiGood would like to continue to offer free or cheap service to individuals and premium service to corporations. The logic goes something like “we’ll attract consumers and that will lead to corporate customers”. But from the foregoing it should be clear that WikiGood is missing the opportunity to activate those very consumer-users, by failing to provide a vision for Jessica that looks substantially better than the walled-off nightmare. Users have little incentive to induce employers to switch to gmail for instance, if that would lead to each user having two gmail accounts instead of one. That situation is not appreciably better than the situation where the user has a gmail account and a corporate Exchange account. Contacts are still separate. Searches still fail to find results across accounts. The tags created for one account are completely separate (and return separate results) from the tags created in another account.

Many Lives — Just One You

The key missed opportunity is for WikiGood to acknowledge that users often act as agents for other legal entities. I’m using agency in the legal sense here. First from the American Heritage Dictionary:

One empowered to act for or represent another: an author’s agent; an insurance agent.

And now from the Agency (law) entry in Wikipedia:

The Agent’s primary fiduciary duty is to be loyal to the Principal. This involves duties:

• not to accept any new obligations that are inconsistent with the duties owed to the Principal. Agents can represent the interests of more than one Principal, conflicting or potentially conflicting, only on the basis of full and timely disclosure or where the different agencies are based on a limited form of authority to prevent a situation where the Agent’s loyalty to any one of the Principals is compromised. For this purpose, express clauses in the agreement signed by each Principal with the Agent may identify specific types or categories of activities that will not breach the duty of loyalty and so long as these exceptions are not unreasonable, they will bind the Principals.
• not to make a private profit or unjustly enrich himself from the agency relationship.

In return, the Principal must make a full disclosure of all information relevant to the transactions that the Agent is authorized to negotiate and pay the Agent either the commission or fee as agreed, or a reasonable fee if none was agreed.

If WikiGood introduced the concept of agency into its system, it would enable Jessica to have a consistent identity over time as she worked in her own interest, or in the interest BigBoxCorp or NowYouSeeIt, yet retain full visibility across all her content.

The core concept, is that within each application, a person has the ability to act as an “agent of” some identifiable “interest” or “principal” — think “employer” or “customer” or “client”. But the person retains her identity — the system always knows the person’s identity. There is one set of authentication credentials. Knowledge expressed to the system by the person is retained by the system and associated with that person — regardless of which “principal” they represent moment-to-moment.

In this way, principals can have (purchase) rights in the system, and those principals can assign their agents limited rights in the system too. The user switches between agencies as she operates. She expresses this switch through the user interface. If you’ve used a mail client that lets you select from multiple “from” addresses when sending mail you have the basic idea, only you’d make a “working for” selection each time you changed tasks. Perhaps you could “work for” more than one principal at a time — why not?

Instead of requiring the user to do this switching, perhaps smart systems could infer agency on-the-go based on time of day or content or physical location of the user. These smart systems could prominently display their guess and the user could change it if it was wrong.

In this way, no “closed system” like VPN is required to protect a principal’s interests. The principal contracts with various service providers the terms under which its agents can act. Principals then assign rights to their agents. But principals create no identities — they just assign rights/trust levels to identities. In this way one identity can serve many principals. There may be a notion of the “public domain” principal, so an individual has the ability to do work for the “public domain” or in the public domain.

What it Would Mean

The Agency-Aware Identity Model gives rise to a new business model where consumer accounts and consumer loyalty can be parlayed into corporate accounts. Each consumer-customer of a Web Service will now be highly motivated to induce each of the principals on whose behalf they work, to also become (corporate) customers of that same Web Service. Corporations (principals) would retain the important security and control capabilities they have today with their enterprise identity model: a) the right to assign and revoke privileges/trust to individuals (agents), b) the right to protect (privacy) information produced by their agents c) the right to eaves drop and monitor the activities of their agents for e.g. regulatory compliance, sexual harassment violations, EEOC etc. An individual, by agreeing to operate on behalf of an agency (for a period of time, or for a particular task) is potentially forfeiting some privacy or future access rights to her work product.

So what do you think? What would it be like to use WikiGood or your-favorite-web-app-here and never have to log out regardless of which client/principal you were working for moment by moment? How much more effective would you be if for each application, all your information in that application category was available at once? Would you be able to remember to click the drop down list of agencies as you switched between tasks during the day? Would you want that switching integrated with your web SSO system like OpenID? Do you believe that by adopting an Agency-Aware Identity Model, WikiGood could effectively turn its non-corporate customers into a rabid enterprise sales force? I do.

Are Web services on the Web, or do they have to use SOAP? How is low REST different from high REST? Does XML/HTTP work better if we call it POX? When is AJAX not AJAX? Who owns the semantic landscape?

There are also a lot of people building applications, that don’t have time to argue how you call it or what it means, just as long as it works. We call them, “the pragmatics.” This post is for them.

When it comes to designing Web services, there’s a few choices of architecture style, and stacks of technologies to choose from. It’s still undecided which one will rule them all, the race if far from over. Most people who write about that stuff hope their horse is the winning one.

I’m no exception. So I’m going to play pundit and tell you which architecture style I think works best for the Web, which technology stack I prefer to use:

• Architecture style: use the simplest most common solution to solve your problem.
• Technology stack: see above.

XML over HTTP (can we please not use an acronym that means a disease?) is great for moving structured data around, and shines at encapsulation. Its loosely coupled document style has too many merits to mention. Except when you’re building a UI that needs to talk back to the server, where tight coupling is good enough, and too much abstraction means you’ll never deliver on time.

RSS is a wonderful way to stream data updates from server to client, not to mention the magical combination that are blogs and feed readers. It’s the ultimate query API. Except when your UI is trying to query the number of unread e-mails in your inbox, and you find out that RSS is anything but simple.

Microformats are amazing in their beauty and simplicity, and let you easily microchunk your content. Until you fall in the 80% of problems they were never intended to solve and… well, just don’t solve.

JSON (not to be confused with Jason, though they both love AJAX) is the simplest form of API you can think of, concise and easy to use. It’s a wonder it wasn’t invented earlier. Except that it’s tightly coupled and still envious of what XML can do for you.

AJAX is great even though almost everybody is using it for HTML. But let’s not get too tangled up in detail, acronyms are not for describing but for branding.

There’s nothing like REST, it powers the Web (can we get a logo for that?). You’ll just have to ignore all those big name Web sites we all like to mention that use cookies for the benefit of their users. And all the REST APIs that violate more constraints than a drunk driver speeding down the wrong side of the road.

RDF is semantic bliss, it gets semantics right and has a thoughtful model for representing and querying it. You can do amazing things with it. But most likely your semantic data is not RDF, and still happens to work, and you’re cursing every time you need to fix Firefox configuration files in all their semantic glory.

The Web thrives not because it uses a strict architectural style and a coherent technology stack. It thrives because so many sites pay little attention to REST and choose to focus on their users instead. It thrives because malformed HTML pages include GIFs and PNGs and Flash and badly written JavaScript that just works. It thrives because people go on the Web to send e-mail, IM, do VoIP and trade BitTorrent files.

The search for the holy grail, the one technology to rule them all, is as old as technology itself. I’m fine knowing we’ll never settle the score, never know whether vi is truely better than Emacs, or whether Eclipse shadows them both. But unless you’re a vendor making money on one horse, it doesn’t matter to you.

If you’re a pragmatic developer, you have one tool in your toolbelt that always wins the day. It’s the ability to think, ask questions and make choices. To choose solutions that are best for the problem you’re tackling right now. And to keep learning. Because there will always be some new technology that’s better at solving some use case or another.

The only architecture that matters is the simplest one you can get to solve the problem at hand.

This post: written in Vim, formatted as HTML, available over RSS.

Recently David Heinemeier-Hanson asked “How do we fork the word enterprise?”. This will do for now.

via Patrick Logan and Mark Baker

On March 7, in his talk at the O’Reilly Emerging Technology Conference, Ray Ozzie, CTO Microsoft, demonstrated (short screencasts, live demo page) a method by which users can cut/copy/paste structured content between web applications and between web applications and Windows ones. Alert lesscode readers will notice that Ray’s blog post describing his inspiration and motivation for the idea bears a striking resemblance to my own post from last October. A deeper look at the screencasts, the live demo and the technical introduction remove any doubt that what Ray demonstrated, and in fact what Microsoft is offering under the Creative Commons Attribution-Share Alike license (you heard me right) is in fact the Web Application Clipboard as described in that original lesscode post and followup.

This is in no way meant to diminish the Microsoft folks’ brilliant implementation. The portable trick used to actually hook the browser’s built-in cut/copy/paste functionality is inspired. The design tradeoff resulting in a visible representation (scissors icon) of every clipboard-capable element is all their own, and quite frankly, is probably a necessary tradeoff if the Web Application Clipboard is to actually get traction. There’s a more technical analysis posted on my personal blog, but the executive summary is:

Live Clipboard (Microsoft’s name for Web Application Clipboard) is awesome and I believe sites will adopt it. I wish the name weren’t “infected” with the Windows Live brand but that won’t matter a whole lot so long as the specification is good and open. Right now though I can’t find any specification at all but I’m keeping hope alive on that front anyway (you listening Gandhi? MLK?)

What I find more interesting than that technical stuff though is the amount of mindshare this thing got “all of a sudden”. First off, note that Ray’s March 7 blog post on this subject comprises the only thing he’s blogged since the end of January. A whole month of the Microsoft CTO’s time — how many dog-years is that? Now realize that the good guys over at the Gillmor Gang podcast spent a full 48 minutes on this single topic on March 16 (Ozzie Gang I, Ozzie Gang II), most of which was spent interviewing Ray Ozzie himself. They were downright effusive. From Ozzie Gang II:

• Mike Arrington, 4:45

  Does this signify any sort of shift organization where people in microsoft who have ideas that can help the Web… that they can also get things through the politics and through the system fast enough so it doesn’t take and years?

• John Udell, 17:52

  Ray this is great. I just personally want to thank you for doing it. I think it’s a tremendous step.

• Steve Gillmor, 17:57

  Yeah, and I think that everybody is knocked out that somebody with your intuition is in such a powerful position at Microsoft. You know, bringing Microsoft into the community has been very difficult to do and you seem to be doing it.

• Dan Farber, 18:31

  I think as everybody on this call has said, we’re quite impressed with this very simple little notion that seems to be well executed and that it comes from Microsoft now really injecting itself into the big old Web community. It’s cool!

• Dan Farber, 19:13

  If you go to the desktop and you consider cut and paste, copy and paste, you know it’s everywhere… to be able to do that on the web… it’s like a big gift — it’s a contribution to the Web.

• Mike Arrington, 22:18

  I think the big story here is that we’re starting to see with Ray’s leadership that Microsoft is able to do things that seem selfless and simply good for their own sake and SSE is one example and (Live Clipboard) is another stunning example…

• Steve Gillmor, 24:05

  I think that Microsoft may well be on the threshold, whether they fully realize it or not at all levels of the organization, of winning by accepting a part in the community, and I think that’s a huge story.

Strange and wonderful times indeed.

Don has effectively made the observation that a lot of other people (especially of the Web services sort) have made; while the benefits of GET’s transparency are obvious, they’re less apparent for PUT and DELETE, so why not just take the easy (lo) road and use POST?

I think there are two answers; 1) hopefully, we’ll have some concrete benefits for that transparency some day (think offline), and 2) thinking in terms of GET/PUT/DELETE first — using POST only as an escape hatch — leads you down a path where your application will be using transparent methods a lot more than opaque POSTs.

I’ll use my first post here to repeat the ideas from Bill’s post…

I think a cargo cult of REST has indeed emerged, and I’m seeing evidence of it on the ground, far from SOA discussions. I’m seeing REST evoked as something that is inherently good. I’m seeing people ask for REST support in their frameworks. I usually know what they mean, but their requests seem to be driven by the truthiness of REST, not the utility.

For instance, I often get annoyed with URI design discussions, where people put great importance into abstract design issues that no one else will notice or care about. In HTTP (and REST) URIs are supposed to be opaque strings, so why the obsession? I call bike shed. People are tackling the pointless decisions first, because they are low-stake and easy to think about. It also comes from an inversion of logic: good things are generally aesthetically pleasing; but many things that are aesthetically pleasing are superfluous and distracting.

What’s useful is that REST design doesn’t promise anything more than it can deliver. It doesn’t promise anything general about the body of the response (except I suppose that Content-type and other metadata will be accurate). It doesn’t promise anything about the URI. The use of verbs is in part to make the URI more opaque, so instead of rewriting the URI to express new actions, you use different verbs on the same URI. GET actually means something to intermediaries. POST, PUT, and DELETE only really mean something to humans. Which is okay, but it’s not interesting architecture.

It’s not bad to use these verbs, it’s just not particularly useful. I think High REST may be the result of people who just can’t help but make architecture. Low REST is people who are recognizing emergent architecture. REST isn’t a new idea, it is the recognition of the good ideas that are already around us. And like design patterns, the description is turning into prescription, and as with patterns we are seeing people use REST to justify premature architecture — probably a much worse sin than permature optimization.

I look at a protocol like OpenID which is wedded to HTTP and HTML — and even intimately connected to those poorly-specified browsers that we all can’t help but hate — and I think that’s great architecture. It’s not great because it is pretty underneath (it isn’t), it is great because it solves a hard problem inside fixed constraints without exceeding scope. It’s RESTful at heart, but not RESTful in form.

If there aren’t concrete benefits to using PUT or DELETE over POST, then why should we care? What hard problem is made easy? High REST seems to be uncovering non-problems.

From an old thread on WebDAV methods:

REST encourages the creation of new methods for obscure operations, specifically because we don’t want to burden common methods with all of the logic of trying to figure out whether or not a particular operation fits the 99.9% case or one of the others that make up 0.1%.

That doesn’t mean you want to make up a new method if you don’t have to, like getStockQuote. Use GET /stockQuote/43 for that. A small number of methods will get you pretty far, but perhaps not all the way. For authoring applications, you’re likely to hit some snags. You’re also likely to hit some religion.

You have $100 engineering dollars to spend. No matter how many millions we’d actually wind up spending, we use $100 as an easy number for people to keep in their heads.

There are well over $100 dollars worth of features you want.

The challenge is in determining how to spread the $100 in a way that produces with the most aggregate value.

I find myself in near-total agreement with Dare, except that I would take all that C# money and spend it on IronPython. This is lesscode, and we don’t believe in 48-character method names that VisualStudio autocompletes for us. :)

I find it particularly interesting that he allocated $40 to “better support for consuming XML in the browser.” Well, what a coincidence. I’ve been spending some time sheparding a JavaScript SAX interface through the Mozilla process. Now, I certainly don’t have any decision-making power, and I don’t speak for Mozilla, but wouldn’t it be cool if Microsoft exposed SAX to JavaScript? That could speed up a lot of AJAX. MSXML SAX objects are already available to client code as ActiveX objects, but you can’t write a ContentHandler in JavaScript for Internet Explorer. Bummer. Why not? AJAX developers are getting pretty good at event-driven code.

This is good news, though I’m a bit taken aback it’s happening so soon. Some people would say it should have happened half a decade ago, but I’m something of an optimist.

REST has always been a solid basis for designing distributed systems, it comes with a theory (I know! It’s crazy!), appropriate and specific to the web domain. It has not been a populist approach, which can be summed up with – “where are the REST toolkits?”.

All that is about to change. REST has won. Fire up your editors.

Have nothing in your house that you do not know to be useful.

Now what?

When REST becomes a mainstream/default development approach, as opposed to a fringe/implicit one, a couple of things come to mind on the plus ca change front. First off, I think you’ll see better support for URI design and mapping onto code in server libraries. Also, better access to headers (especially caching and timestamping directives). More awareness and support for the full range of HTTP methods and response codes. Attribute modifers and declarations on methods that have side-effects. Exception designs based around 5xx and 4xx response codes. Media type dispatching. Less emphasis on cookies, more support for digest authentication. More flexbility in LAMP stacks for writing out stuff that isn’t HTML (esp. JSON and Atom serializers). That sort of thing. Overall a gradual lifting on HTTP/REST concepts and idioms into application code.

But probably the most important initial effect is how minimal and frugal REST will seem to the working developer.

This Spartan Life

If REST has an analog in building architecture, it’s Modernism. On the web, hard lines are where it’s at, and less, really, is more.

REST is about design constraints – what you can’t say. That’s contrary to industry practice, where it’s all about about getting cool new features piled on, and to heck with principles. If anything, most developers are cynical about architecture and architects. Developers, Developers, Developers. Give ‘em what they want. Keep ornamenting the stack with pointy-clicky solution cruft.

There’ll be a bit less of that. On the web, there are less assumptions you can make and those you can make are rigid and need to be treated as invariant. Developing for the web, as opposed to developing around it, is spartan work. Coming from middleware and enterprise development, could be a bit like coming from the Victorian ornateness and richness of Ruskin and Morris to the urban cold and minimalism of le Corbusier and Mies van der Rohe. It’ll be disorienting at best.

For example, tool support will go from “non-existant” to “sucks”, initially.

All one can say is that the laws and liberties, such as they are, which govern local/LAN-based software development don’t always apply when it comes to Internet based development. In point of fact they’re often a hinderance, and there’s a history of getting burnt on bad assumptions on the Internet. You can try to make inter-network, cross-administrative systems development transparent, to look and act like middleware. But you won’t. Noone has.

The solution is invariably to take the assumptions and patterns and cute tricks away, and replace them with forcing functions in the form of design constraints that keep developer and system behaviour aligned. Even stuff that enterprise developers would tend to know, like caching, needs a different approach. Them’s the apples. REST is a collection of such constraints, formalised into an architecture.

Perhaps the key thing is education, and teaching.

I think we’re done more or less with the evangelism and technical food fights with the WS-* and Enterprise crowds. It’s time for REST to proceed on its own terms and not in contrast and counterpoint to something else. Teaching, on how to target and design with REST, particulary for HTTP as deployed, needs to ramp up. Certainly we need a few good practical books on REST/HTTP to ship.

At least one of those fine books should cover the fundamental principles of Web-centric development, the way Gamma et al did for C++ Patterns, Fowler did for Refactoring, or Norvig/Graham did for CLisp. Something that nails it. As things go, Fielding’s REST thesis is pretty accessible, a decent read even, but it’s a doctoral thesis, not a textbook.

Tickbox Gartnerfication

Hype could be a problem for REST if the “industry” gets on board with it as a commmercial factor that requires ticking off rather than some dorky engineering stuff – “Do they have REST? Check.” So will keeping an eye out for land-grabbing on the term “REST”, so it remains a crisp technical term (It has a theory?! I know! It’s crazy!).

Avoiding the descent into marketing farce, a problem that has plagued “SOA” and “WS” can only be a good thing. To be honest, I’m not holding much hope on this one.

God is in the details

Let’s be realistic. No software architecture can truly withstand implementation. REST is really great, but on the web, there is plenty of detail work to be cleared out, like push, containership, encoding, side-effected GETs, curse-of-popularity, queuing, 2 versus 4 methods, universal format junk, and authentication, among others. I could go on, it’s messy out there.

Issues like these will become more important, or more distracting, depending on your point of view, as the style gets adopted. So run away screaming from anyone who dismisses these as “just implementation details” – implementation details matter. They cost money, and break hearts.

Lot’s of work has been done. There’s lots of work to do.

PS.: in case anyone thinks there’s some kind of collective REST triumphalism going on @lesscode, there isn’t. I’ve been sitting on this post over the St Pats weekend, only to find out that Sayre and Tomayko have posted REST stuff in the meantime. You’d swear they weren’t Irish.