"Open Space Coding Day"

Time for a little reflection. Over the last year, I think that a great deal has been achieved in the Alt.Net community in the UK. We have had two conferences and Sebastian Lambla has now ran four Alt.Net Beers. These have stimulated healthy discussion in the community which I am very happy to see and we should continue to nurture.

In the spirit of continual improvement, I have been thinking about how we can build on these successes and one question in particular comes to mind: "how do we move from talking to doing?". I would also like to foster a feedback loop into the conferences so that the conversation has forward motion.

My draft proposal to the community is to host a series of what I am currently calling "Open Space Coding Days". I would like these to be on a regular basis, rather like Alt.Net Beers. The focus should be on hands-on activity rather than general discussion but the Open Space philosophy still applies. Accordingly, the activities should be self-organizing. This is not about speakers or powerpoint. The only requirement we should have is to publish the code in an open repository and notes in a wiki.

Before I get tackled on the subject, for all I know this is a format that has been tried elsewhere. I suspect that the model might be very near to a BarCamp but as I haven't been to one, I don't know.

I am very interested in taking feedback. The following jump to mind but the list won't be exhaustive:

• Would you be interested in attending such an event?
• Would you or your company be interested in sponsoring?
• I have in mind to do this on Saturdays - do people think this is the right day?
• What is a reasonable number of people for a hands-on event like this (I suspect it will be fewer than for a conference)?
• How often should the event be run? Monthly? Every other month? Some other period?
• Should it run separately to Alt.Net Beers or seek to work together (perhaps planning events to coincide)?
• Is it reasonable to require attendees to bring their own laptops and have development software already installed? If not, what are the alternatives?

I am in discussions with Conchango to host the first of these as they were so supportive with our first Alt.Net UK Conference. Dates are still open as I write this.

Update (9th December)

Conchango have kindly agreed to be venue hosts for Open Space Coding Day 1. This will be on the 31st January at their London offices.

I was expecting to have to put up a reservation form, but in a flurry of tweets during today almost all of the places have been taken! Taking a leaf from Scoble, I thought I would see how effective twitter would be as an organising tool and I am very impressed! At the time of writing, there are a couple of places left. All the places have now been taken. If you wish to go on the waiting list please contact me either on twitter.com/adean or email alan.dean@gmail.com. If you can't make it on the 31st, don't worry - I will be running the event every other month, so you can always catch it next time around. People on the waiting list will be given first refusal on attending subsequent events so that there is a variation in attendees between events and that people don't feel left out. Therefore it is worth letting me know that you would like to come.

When I was at the PDC, I found it very annoying that there wasn't a consistent hashtag in use. Therefore, I would like to propose that we standardise on a single hashtag for these events. I have started using #openspacecode - the only other option that came to mind was #oscd, which (whilst shorter) just seemed too arcane to me.

Following the principle of 'golden hours', there will be two coding sessions of two hours in the day and a generous period of time for socialising over lunch:

The planning process will be as follows:

1. Attendees put up the sessions they are interested in having
2. Attendees put their names against sessions they are willing to host. No host means the session is dropped. Be aware: the host is not a presenter, the host is not expected to even know the subject. The host is simply someone to keep the session flowing effectively for the participants.
3. Attendees vote on which proposed sessions get the go-ahead.

The only exception to this process will be that I am going to try to have one 'keynote' session per event. On the 31st January, Barry Dorrans (Security MVP) has kindly agreed to host a session on "Hands-on secure development". It's certainly one session that I want to be part of!

Please remember to bring your laptop. If you don't have one, then you will have to share. There will be WiFi access available. I will be putting together trial Virtual Machines for anyone who isn't an MSDN subscriber or hasn't got Visual Studio installed. Important: if you want to propose a session using a different development environment, for example using Mono on Ubuntu, please contact me so that we can arrange a VM. These session are about doing, not presenting, and so any proposed sessions that attendees cannot participate in will be dropped before voting.

Partnership or Company?

At DDD7, I had an interesting discussion about the question of whether a partnership or a company is the better model for a consultancy.

I think that the accepted practice is to incorporate as a limited company. Certainly I can see advantages in doing so: in tax treatment and the limited liability that it offers.

However, I wonder if partnership is a more appropriate model; even potentially a more ethical model.

The joint and several liability of partners requires that they treat business with care. It is interesting to note that both lawyers and accountants, both classes of fee-earning professionals, either often use partnership or are even required by law to do so. I don't know what the practice is for other types of fee-earning professionals, but I would be interested to find out.

Looking at the current devastation in our financial markets, I ask myself if the mighty investment banks would have placed such huge and arguably unwarranted risks if they had remained the partnerships that they were, rather than change to corporations. Similarly, would the UK Building Societies which relinquished their mutual status during the 1990s have fared better if they had not done so?

My thoughts on this subject are not fully formed but I do have a nagging suspicion that we ought to consider which is the appropriate model.

I would be very interested to hear what people think - especially those who are customers of consultancies. Would you have more or less faith in a business where the partners did not have limited liability? Perhaps you prefer dealing with companies? Either way, what would be your rationale?

For quite some time I have had a feeling that we need to mature as a profession, that there will come a time when our customers will expect the same level of professional certification and regulation that they have with other service providers such as lawyers, accountants and engineers. Perhaps the kind of organisations we work for will be part of this maturation.

DDD7

I thought that Developer Day 7 was another resounding success. As usual, the organisers deserve kudos for arranging what has to be the premier UK Community event.

If you were an attendee, please take the time to fill in the feedback - the speakers all appreciate this a great deal.

I was in the first tranche of presentations in Memphis at 09:30 and all the seats were taken (typically a good sign). It was the first time I have given the "Separating REST Facts from Fallacies" talk to an audience and was pleased that I timed it right, completing it with a little under 5 minutes for questions. It is a bugbear of mine when speakers overrun their timeslot so I take this very seriously in my own presentations.

There were surprisingly few questions at the end but those that were asked were good. I had prepped for a number of questions that I had expected to be faced with, but wasn't. One of my friends who was in the audience reported overhearing a conversation where the comment was made that the presentation was 'religious'. If that meant that they could tell that I believe in REST where appropriate, then that is good. If that meant that they felt that the presentation was unbalanced, that is not so good and would be surprising as I made a particular effort in the talk to avoid setting up the typical dogma of "REST Good, WS-* Bad".

In any event, the Channel 9 folk were there to video all the sessions this time so you will be able to judge for yourself. Historically, only a limited number of sessions were recorded. I don't yet know where the videos will be hosted but I will announce when I find out. It is going to be interesting, to say the least, to see myself giving a presentation as I haven't previously done so. I imagine that I will be squirming in my seat and will be my own worst critic.

The Geek Dinner in the evening was great fun. Thanks to Zi Makki for organising that. The conversation is always stimulating and I had a couple of very interesting discussions about REST and other subjects. I really do enjoy the networking aspects of these conferences - a chance to meet and talk with others who are as passionate about technology and self-improvement as I am.

Phil Winstanley and Craig Murphy have both pushed up their photos to Flickr (I didn't take any).

developerday.co.uk error

There appears to be some kind of problem with the DDD website right now.

Don't fret! You can still reach it at http://216.247.126.58/DDD/

"Windows Live Sync replacing FolderShare"

I have been a long-term user of FolderShare from before Microsoft bought it in 2005. Indeed, it is central to my personal backup strategy. FolderShare seemed to languish for quite some time but unlike OneCare, it isn't going to die but is going to be re-born as Windows Live Sync instead. Watching the progress of Live Mesh, I've been expecting something like this for a while and it makes sense to have a common platform for this kind of functionality from Microsoft.

OneCare, RIP

I was very sad to hear of the impending demise of OneCare. I am quite a fan of it and have licensed it on all of my own machines and those of my family. It is unobtrusive, unlike so many of the alternatives and has the quality of 'it just works'. I can only assume that it hasn't made enough money. Microsoft are dressing the decision up as "Improving Global Access to Core PC Protection" but I can't see that offering "Morro" requires the cessation of OneCare. Occam's Razor therefore indicates a financial motive.  It isn't going to die immediately, but subscriptions will be cease to be available from June 30th 2009.

P.S. It seems that a 'morro' is "a rocky outcrop in the shallow waters of a harbour, often round in shape and sometimes very high". It is also the name of the harbour fortress of Havana, Cuba.

Federated HTTP Authentication

One of the questions that has not had much discussion recently in the REST community is authentication and authorization.

Cookies should not be used by a system which is to be considered RESTful. Roy has explained why a number of times.

I have looked at both OAuth and OpenID, but they do not seem to have a good story for automated agents as they focus on having human interaction in a browser session.

What would be ideal is a standardized authentication mechanism that supports federation. The obvious candidate is HTTP Digest Authentication (the specification isn't the easiest read, I have to admit, so you might find the wikipedia entry more understandable). Granted, it doesn't have a pretty logo. But it is supported by every user agent that I know of that is HTTP-aware. What isn't clear, however, is if it can be federated to permit user agents to employ a separate Identity Provider, reducing the need for multiple online identities.

This is an itch that I have been scratching in my mind for a while and I brought it up in conversation with Steve Bjorg yesterday. This gives me a reason/excuse to post where my thoughts are on the subject right now. Please note that these thoughts may well change and I do not consider myself a security expert.

The following diagram outlines the sequence diagram that I have in mind. Important: There is a precondition that the Server already has knowledge of the location of the Identity Provider for the user. This would probably be achieved manually in the same way that OpenID does, including an 'allow access' screen.

This is what the HTTP messages might look like:

The Client makes an ordinary GET request to a resource that happens to be protected.

GET /dir/index.html HTTP/1.1 Host: example.com

The Server crafts a fresh WWW-Authenticate header and sends it to the Client with a 401 Unauthorized status code.

HTTP/1.1 401 Unauthorised Date: Sun, 10 Apr 2005 20:26:47 GMT WWW-Authenticate: Digest realm="realm@example.com",                          qop="auth,auth-int",                          nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",                          opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: text/html Content-Length: 311 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd"> <HTML>   <HEAD>     <TITLE>Error</TITLE>     <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">   </HEAD>   <BODY><H1>401 Unauthorised.</H1></BODY> </HTML>

The Client crafts an Authorization header by hashing the user credentials with the parameters of the WWW-Authenticate header in the normal fashion and resends the original request.

GET /dir/index.html HTTP/1.1 Host: example.com Authorization: Digest username="Mufasa",                       realm="realm@example.com",                       nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",                       uri="/dir/index.html",                       qop=auth,                       nc=00000001,                       cnonce="0a4f113b",                       response="6629fae49393a05397450978507c4ef1",                       opaque="5ccc069c403ebaf9f0171e9517f40e41"

Here is the cunning part. The Authorization header contains enough information that a hash comparison can be carried out by anyone who has the correct credentials at hand. It doesn't have to be the Server. Therefore, the Server passes the Authorization header to a previously stored Identity Provider URI for validation (in this case, on http://example.org).

GET /user/Mufasa?domain=example.com HTTP/1.1 Host: example.org Authorization: Digest username="Mufasa",                       realm="realm@example.com",                       nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",                       uri="/dir/index.html",                       qop=auth,                       nc=00000001,                       cnonce="0a4f113b",                       response="6629fae49393a05397450978507c4ef1",                       opaque="5ccc069c403ebaf9f0171e9517f40e41"

The Identity Provider retrieves the password of the user and performs the hash comparison. If validation fails, a 401 Unauthorized is returned to the Server. If it succeeds, a 200 OK is returned.

HTTP/1.1 200 OK Date: Sun, 10 Apr 2005 20:27:03 GMT Content-Length: 0

The user is now authenticated. The Server can check permissions and respond with the representation requested, if permitted. A 403 Forbidden would be sent if the authenticated user is not permitted.

HTTP/1.1 200 OK Date: Sun, 10 Apr 2005 20:27:03 GMT Content-Type: text/html Content-Length: 7984 ...

There are some optimizations that could be employed. The Identity Provider could issue validation for a given period by setting the Expires header on the validation response, indicating that the Server can cache the authentication for a period. Similarly, the other conditional HTTP headers could be employed for more complex caching.

The communication between Client and Server and between Server and Identity Provider does not need to be encrypted because the credentials are always hashed on the wire, mitigating a man-in-the-middle attack.

The Client does not need to know anything about the Identity Provider. So far as the Client is concerned, this is a perfectly ordinary HTTP Digest Authentication mechanism which gives two benefits:

• There is no need for a complex set of Client HTTP requests to achieve authentication.
• The REST Layered System constraint is not violated.

I am interested to hear feedback from my audience if this is an authentication model that would be useful. As I said at the top, I am not a security expert so there may be flaws in my thinking.

On RESTful Basket State

In two previous post ("When Basket Checkout isn't RESTful" and "What a RESTful Basket Checkout might look like") I have referred to the question of where basket state should be stored in a RESTful system. A number of conversations have ensued from these posts that I feel warrant a deeper post specifically about this question.

I will start by describing the typical basket / checkout implementation (which isn't RESTful).

The vast majority of web sites require that you authenticate (or are 'authenticated' as a new anonymous guest). A token is then passed to the client which is a reference to session state on the server. The user then browses the site, adding to the basket as they go. When the time comes to checkout, the client simply passes the token back to the server for it to retrieve the session state internally:

From the perspective of REST, this breaches the Statelessness constraint. From a more general perspective, the basket implementation is tightly coupled to the checkout implementation which leads to a monolithic Store Application. Serendipitous reuse is reduced or prevented. If a requirement is received to implement a rich client, for example, then either the client has to carry out site-specific work to orchestrate the basket and checkout or significant server changes must be carried out.

Moving away from this model requires that the client maintains the basket session state. For a browser, this might be in a local cookie or by using a browser extension such as Google Gears. For a rich client, this might be simply kept in memory or in a local data store. The specifics do not matter from the perspective of the client/server interactions:

 

The client does not need to interact with the server until the basket is ready for checkout. Where does the client get the data to build up a basket? It doesn't matter to the Checkout Application, which is no longer monolithic. Instead it is entirely decoupled from the rest of the store. Serendipity is enhanced because clients only need to know how to construct a valid basket representation and how to authenticate. In a RESTful implementation, the basket representation will be rendered using a standardized media-type and authentication will use a standard authentication mechanism such as WWW-Authenticate.

In "What a RESTful Basket Checkout might look like" I discuss, in passing, what a RESTful implementation of basket persistence might look like. Many online stores allow the user to add an item to the basket and then to come back in 6 months time and still see the item in the basket. Alternatively, perhaps the user should be able to see the items in the basket when they use a new machine. Clearly, a RESTful implementation should allow for such functionality.

REST has a Layered System constraint. So long as this is not breached (by, for example, the checkout knowing about the basket persistence mechanism) the client is allowed to compose multiple RESTful services. In this case, the client would compose Basket Persistence with Checkout:

The client is free to use whichever persistence implementation is desired. Perhaps one client implementation will use Amazon S3. Another might use the data capabilities of the new Azure platform or employ a custom persistence solution. The checkout application doesn't care.

I hope that this clarifies some of the questions and answers arising from my previous posts.

"Separating REST Facts from Fallacies" at DDD7

This is the talk I will be giving at DDD7:

View SlideShare presentation or Upload your own. (tags: rest)

What a RESTful Basket Checkout might look like

In my previous blog post, I discussed "When Basket Checkout isn't RESTful" so here are some thoughts on what a RESTful implementation might look like.

This is what I want to have as the final step of transitioning to checkout (where application/basket+xml is a standard media type):

POST /checkout
Content-Type: application/basket+xml

<basket xmlns="http://example.org/basket">
<item id="1" count="1" product="http://example.com/product/green-ham" />
</basket>

This is deliberately trivial xml as the format itself is not especially important. What is noteworthy is that the basket contains all of the items that the user wants to purchase. The basket state might have been constructed without ever previously visiting the server, perhaps in a rich desktop client.

Upon receipt of the basket xml, the server sends a WWW-Authenticate challenge to authenticate the user. If the authentication succeeds, it continues with whatever workflow it has for checkout.

Note how this request fulfils the REST constraint to manipulate resources through the exchange of representations (in this case, of a user basket).

After checkout, the server would likely expose the current state of the order to the authenticated user, for example:

GET /order/abc123
Content-Type: application/order+xml

<order xmlns="http://example.org/order" total="12.34" xml:base="http://example.com/order/abc123" currency="GBP">
<item id="1" count="1" product="http://example.com/product/green-ham" price="12.34" />
<payment>...</payment>
<delivery>...</delivery>
</order>

OK, so now you can see what the end objective looks like, it makes the client side journey a little easier.

If the client is a rich client, life is simple: just store the basket state in memory or persist it to a local data store as desired. When the time comes to checkout, the necessary basket xml is crafted and then sent to the server using something like HttpWebRequest. All runtimes expose the functionality to send HTTP messages these days; read your documentation for guidance.

If you are in the browser then you will need to store the data locally as well. There are a number of alternatives. The most obvious is in a client cookie, but you could also use Google Gears if it is installed.

In my previous post, I discussed the proposal by serialseb for a 'personalized resource'. Purely in context to the client needing to store the basket state, this makes sense. You might, for example, have requirement to remember the last basket state in order to highlight previous purchases. What is imperative, however, is that only the client has knowledge of this 'personalized resource'. At no time does the server which will checkout the basket ever know about where the basket state is persisted. In fact, this is an excellent example of meeting the Layered System constraint of REST and applying information hiding.

For my money, that is a RESTful Checkout.

When Basket Checkout isn't RESTful

Following on from my twitter chat, here is why I think that the following two basket checkout styles are not RESTful.

GET /checkout

When the server keeps session state about a user basket (cart in the US) you will tend to see checkout as a regular GET. This is because the server keeps track of all the "Add to Basket" choices of the user. Somewhere, a token is being kept that links the user to the session state on the server; this may be a token in the URI, in a server cookie or in ViewState. Whichever method is chosen, the significant fact is that the server has knowledge of the application state of the client.

This is in breach of the hypermedia as the engine of application state (HATEOAS) constraint of REST. It also breaches the more general Uniform Interface constraint by failing to manipulate resources through the exchange of representations.

Let me be perfectly clear. This is effectively the standard pattern for implementing basket and checkout across the whole of web. It is perfectly valid as an architectural style: it is simply not RESTful, that's all.

Content-Type: text/uri-list

During the twitter chat, serialseb proposed an alternative approach whereby a 'personalized resource' of the user basket is hosted somewhere. In one version, this can be RESTful (see next blog post) but in another, it isn't.

If the client sends a message (where the provided link is a representation of the basket state):

POST /checkout
Content-Type: text/uri-list

http://example.com/username/basket

Then I don't consider this to be RESTful either because there is no representation being exchanged with the server by the client.

Again, to be clear, it's perfectly valid HTTP - it's just not REST.

In addition to the non-RESTfulness of the style, it has a couple of 'difficulties':

1. Which Content-Type should the server Accept from the provided URI?
2. The application state is inherently confusing. Should the server check if the basket is updated? If it does update, should the server change the order? To the original implementers of such a system, no doubt the answer is obvious but later implementers may not find life so easy. An example of this kind of problem can be seen with OpenID where sites tend to work with a select set of OpenID providers but break with others.
3. Access Control:
   • Does the URI provided require authentication? If not, private data is available for anyone to view. If so, how does the server hosting the checkout obtain the credentials?
   • How is the server hosting the checkout granted authorization to read the basket state?

These problems can clearly be overcome. For example, by complex redirects such as we see with credit card authorization today but the complexity is unnecessary and typically ends up with a situation of bespoke systems integration.

In short, this is another breach of the hypermedia as the engine of application state (HATEOAS) constraint of REST.

Finally, because of the lack of RESTfulness I consider that neither of these options are serendipitous.

P.S.

I forgot to state that the second example also breaches the Layered System constraint because the server has knowledge of the client persistence store. In my following post I discuss using a 'personalized resource' in a RESTful way.

Twittering about RESTful Basket Checkout

I've just been engaged in an interesting twitter chat about REST and basket checkout:

 colin_jack @serialseb ...but as resources in their own right.

 colin_jack @serialseb Yeah, thats an approach I like. I'd make it work as RESTful in my head by not seeing things linked to as part of session state...

 serialseb @colin_jack Well @adean probably has a different and wisest opinion. Mine is that the uri identifying a resource can be a represetnation...

 colin_jack @serialseb Yeah, is it not RESTful? So your saying POST/PUT the basket with URLs of items (sorry, twitter makes discussions hard to follow).

 serialseb @colin_jack Thats where I argue that passing URIs around is not necessarily unrestful, depending on what you do with such uri

 colin_jack @serialseb I guess I just can't see client PUTting all the infromation in those cases, guess I need to read dissertation...

 serialseb @mamund But thats the point. /cv is a generic resource that can have conneg. /cv.doc is a resource that has only one represetnation ever.

 mamund @serialseb it might make more sense if your resource URI was /cv instead of /cv.doc. the "doc" is a 'content-type'

 serialseb @adean I'm looking at it from a webarch point of view. I don't say such distinction is not necessary, but that it doesnt seem to bring value

 serialseb @colin_jack It delves from the argument that state exist within the representations. And that the server shouldnt rely on client behavior.

 adean @serialseb Maybe you don't, but Roy doesn't say the representations are different to resources except where there is only one media-type

 colin_jack @adean I guess I'm just not seeing how posting the whole basket for checkout works, are there any blog entries that specifically cover this.

 serialseb @adean I see no value in distinguishing the resource identified by /cv.doc that exist in one and only representation. A closed IR?

 adean @serialseb He he ... It *does* if you want to call something RESTful :-) It's right there in the dissertation

 serialseb @adean differenciating the representation from the resource doesn't always make sense.

 serialseb @adean you're quire right. As for representations, we need to not downplay the existence of representation-specific resources, for which...

 adean @serialseb As I say, perfectly valid HTTP stuff, just not RESTful (this kind of discussion is why we need to do our two-headed presentation)

 adean @colin_jack But what you are POSTing must be a representation of the basket to be purchsed - that's the key thing

 serialseb @adean transfer would still happen. Unless the resource is local, in which case the server could shortcut the delivery of the representation

 adean @colin_jack You can post to checkout if you want the server to choose the resource identifier: the actual name of checkout is opaque to REST

 serialseb @adean if the server expects a shopping cart representation, it'd request whatever format it understands and become itself a UA.

 adean @serialseb However ... what content-type should the server ask for?? And it certainly doesn't transfer a representations, so not RESTful

 adean @serialseb Yes, you could post a link to the data (assuming that it could be anywhere on the web) if the server supports that ...

 colin_jack @adean @serialseb How about if you have a ShoppingBasket and you POST a CheckoutRequest or something to it, or is that awful?

 serialseb @adean ... on the server? What if the client simply does a PUT with Content-Type: text/uri-list and content being the uri to the basket?

 serialseb @adean agree if it is required for the server to know about the shopping cart to do a checkin. But what about leveraging hyperlink...

 colin_jack @adean Ahhh, yeah. Guess thats why Jim Webber/Ian Robinson and so on are calling their approach Web oriented.

 adean @serialseb Because the 'personalised resource' is optional to clients: they can happily store the app state locally without failing checkout

 adean @serialseb But if the client will PUT the whole basket to checkout (even if there is no 'personalised resource') then that's fine ...

 adean @serialseb if the checkout requires the basket to be in session state (even if exposed as a resource), it's not RESTful ...

 adean @serialseb let's say that the 'personalised resource' is a customer basket ...

 serialseb @colin_jack Well it's not about the tool, it's about the arch. The tool in question provides poor support for what is needed for the arch.

 serialseb @adean ... state of such resource and the mean to interact with it is returned on GET /shoppingcart/2554?

 serialseb @adean Need to define what we cover by state. are you saying POST to /shoppingcart/2554 looses serendipity? Especially when the entire...

 adean @serialseb Sorry Seb, have to disagree - if you do that, you lose serendipity of reuse if the server needs to session state to be present

 colin_jack @serialseb Yeah thats the solution I'd heard of, but if you do go for that then your still breaking the rules Neward talks about aren't you?

 serialseb @colin_jack one solution is to expose the context as personalised urls, aka first-class resources.

 adean @colin_jack I agree with the statement. You can have a well-written Web application and use server session - you just can't call it RESTful

 adean @CAMURPHY Heh, sorry, didn't know that! In that case, I'm definitely up to have it taped :-)

 colin_jack @adean "cannot take advantage of any stored context on the server", just thinking of Amazon working that way...

 colin_jack @adean Already following your REST delicious "feed", he's definitely got a lot of good quotes. Here's a question, how far do you go with...

 adean @colin_jack If you like Roy quotations, I have a bunch of them bookmarked :-) http://tinyurl.com/5w65lu

 colin_jack @adean Fielding definitely doesn't pull any punches! :)

 colin_jack @adean Oh sorry yeah definitely. Still trying to get my head around idea of all state going in each request though...

 adean @colin_jack The fallacy is REST == HTTP, the fact is REST IN {File, HTTP, FTP, Gopher, WAIS, URN, (waka)} http://tinyurl.com/5tbuvp

 colin_jack @adean Would love to hear the talk, which bit is the fallacy (e.g. what he's saying or the other side).

 colin_jack @serialseb Speaking of which I've got to buy Restful WCF when its out! :)

 adean @colin_jack Already bookmarked :-) I subscribe to Ted's blog & this is one of the Fallacies I will be talking about at DDD

 serialseb @colin_jack Very good post indeed. Think Roy should've trademarked REST, would've made it easier. Unlearning Don Box's bs on REST will be...

 colin_jack @iand New REST blog entry from Ted Neward that you may or may not be interested in: http://is.gd/6BAz