Peter Williams

REST vs SOAP

Johannes Ernst posted an interesting comparison of REST vs SOAP (via: James Governor). He makes an excellent point that SOAP URIs point at the type, rather than an instance, of a service. I do not think that the fact that there will be more REST URIs means that this space is more innovative. I am not sure that the number of URIs is, in any way, correlated with innovation. Neither model seems to inherently limit innovation based on URIs, creating a new URI is free and there is an infinite supply (I suppose those two are related) regardless of how you are going to use it.

I think that there will be more innovation in REST architectures because they are more easily understood. REST architectures are easier to understand because they are goal oriented. To use Johannes’ example, the accountant using the system does not want to “calculate this week’s payroll taxes”. She want to know how much this week’s payroll taxes are. If finding that out involves the system calculating it that is fine but the calculation is an implementation detail. The “this weeks payroll taxes” URI is cleaner because it describes the goal rather than the way we achieve that goal this week.

This seems reasonably obvious at the macro level, no thinks that humans should be making SOAP call from their browsers. I think that it makes just as much sense at lower levels. Interfaces, boundaries and encapsulation are for human consumption (the computer would be just as happy without those things) so it makes sense to design those interfaces in a way that is easy for humans to grasp. The data is usually much easier to grasp that the processes using the data. We have know this for year, Frederick Brooks pointed it out in The Mythical Man Month with this statement, “Show me your flow charts and conceal your tables and I shall continue to be mystified, show me your tables and I won’t usually need your flow charts; they’ll be obvious.”

Dan Ingalls said, “If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.” REST architectures will be more innovative because they can be understood by most single individuals.

Subscriptions Microformat (Redux)

Previously I proposed a mircoformat for describing blog subscriptions. Ryan King pointed out in a comment that there is one already, Attention.XML. That does solve my problem.

I do see one potential issue with it. There appears to be no way to distinguish an Attention.xml outline from any other XOXO outline. I suppose it might be acceptable to treat any XOXO block that contains links as a set of subscriptions but it feels a bit kludgey to me. Having an Attention.XML blocks declare their class as “xoxo attentionxml”, or something similar, would solve this problem, and make Attention.XML blocks a bit more obvious. Or have I just missed something?

Tags: XOXO, Attention.XML

Subscriptions Microformat

I am really intrigued by the concept of Microformats. I love the idea of “presentable and parsable” formats.

I am a little disappointed, however, that there is not a microformat for describing feed subscriptions. The de facto standard for subscription lists is OPML. I am not sure how this happened but it does not seem particularly well suited for this task. I think a microformat could work much better. After all, I use my subscription list for just two thing, my blogroll (needs to be presentable) and as the subscription list for my aggregator (needs to be parsable). It would be nice if they were the same and I did not have to keep the two synchronized.

I am thinking something like the following

<ul class="osl" >
  <li class="subscription">
    <a class="title" href="http://pezra.barelyenough.org/blog" 
             type="text/xhtml" rel="feed">Peter Williams' Weblog</a>
    (<a href="http://pezra.barelyenough.org/blog/feed" 
              type="application/rss+xml" rel="feed">RSS 2.0</a>)
    (<a href="http://pezra.barelyenough.org/blog/feed/atom" 
              type="application/atom+xml" rel="feed">Atom</a>)
  </li>

  <li class="subscription">
    <a class="title" href="http://www.toolshed.com/blog/articles" 
             type="text/xhtml" rel="feed">/\ndy's Blog</a>
    (<a href="http://www.toolshed.com/blog/xml/rss/feed.xml" 
              type="application/rss+xml" rel="feed">RSS 2.0</a>)
  </li>

</ul>

That results in

REXML could not parse this XML/HTML: 
<samp>
<ul class="osl">
  <li class="subscription">
    <a class="title" href="http://pezra.barelyenough.org/blog" type="text/xhtml" rel="feed">Peter Williams'; Weblog</a>
    (<a href="http://pezra.barelyenough.org/blog/feed" type="application/rss+xml" rel="feed">RSS 2.0</a>)
    (<a href="http://pezra.barelyenough.org/blog/feed/atom" type="application/atom+xml" rel="feed">Atom</a>)
  </li>

</p>

REXML could not parse this XML/HTML: 
</ul>

REXML could not parse this XML/HTML: 
</samp>

I could style this up nicely for my blog and my aggregator could, directly, use my blogroll as it’s subscription list. Now that would be nice.

Five Weeks

Only five more weeks until my daughter will be born! That is not very long.

It is a planned c-section so we know that she will be born on August 31. The schedule is quite nice with a toddler. He goes to daycare as usual and when I pick him up he will have a new sister. No need to find a baby-sitter that can come over on a minutes notice any time of day or night, etc.

We do not have a name yet, which is freaking my wife out a bit. I have no doubt that we will find a name before we really need it. If we do not settle on one in the next few weeks, however, it could become quite concerning.

Apparently (in Colorado), if you do not decide on a name before you leave the hospital they put “Baby Girl” (or Boy) as the first name on the birth certificate. Then when you decide what the baby’s name is you do a full blown legal name change from “Baby Girl” to what ever name you want. We will definitely not be doing that, it sounds like way to much work.

E4X

Apparently, Firefox 1.5 will included something call E4X. It is an extension that supports easier manipulation of XML. Kurt Cagle has a very nice introduction, Objectifying XML – E4X for Firefox 1.1.

Suddenly, ECMAScript has better tools for dealing with XML than any other environment I know. Those tools will certainly make a lot XML manipulation code a lot clearer. Just as soon as it is supported by all the browsers, that is.