Recently InfoQ did a good summary of the debates around the apparent (to some) limitations of REST when it comes to creating good Web services. At issue is that REST APIs seem to expose "CRUDy" services that fly in the face of years of good services design, particularly when they are just read/write interfaces instead of the richer, full REST architecture (more on what this is later.) The discussion was spurred by Arnon Rotem-Gal-Oz's assertion recently that CRUD is bad for REST, which in my opinion is close but not quite right.

# There are meaningful “entry points” into the app - URIs. (No, I’m not going to mention the R-word.) It’s simply entirely unacceptable for a Web app to expose only a single URI, break the “Back” button, and disallow linking. Frameworks that don’t support URIs for application concepts, such as every customer, order, contact report, document etc. should simply be banned.

# Application boundaries are a concern to developers, not users. The Web is about linking stuff together, without any concern about application boundaries. There’s absolutely no reason why you shouldn’t be able to follow a link in your CRM application that takes you to a product page in your online catalog, or from a customer record to the information about when they last logged in to the Web site, or from a page that’s part of a complex business process UI to the appropriate documentation and on to the discussion group where you can tell everybody how much it sucks.

# Documents are accessible in a standard way. The idea of accessing any kind of document, such as an insurance application form that’s been scanned in, a letter sent to a business partner last year, or a contract with a business partner, by any other means than an HTTP GET is just stupid.

A web architecture should make a best effort to create survivable resource locations, and independent view query schemes, to avoid application silo effects in its choices.

HTML is just one of many data formats on the Web. These are all facts that are not open to debate—they are decisions that we made over a decade ago and reaffirmed by consensus of the TAG. Whether or not Ian agrees with the architecture is irrelevant.

Version béta en cours d'expérimentation. Faites nous part de vos commentaires avant le lancement définitif.

There are lots of reasons for modularity. The basic one is that one module can evolve or be replaced without affecting the others. If the interfaces are clean, and there are no side effects, then a developer can redesign a module without having to deeply understand the neighboring modules.

MOAT (Meaning Of A Tag) provides a Semantic Web framework to publish semantically-annotated content from free-tagging. While tags are widely used in Web 2.0 services, their lack of machine-understandable meaning can be a problem for information retrieval, especially when people use tags that can have different meanings depending on the context. MOAT aims to solve this by providing a way for users to define meaning(s) of their tag(s) using URIs of Semantic Web resources (such as URIs from dbpedia, geonames … or any knowledge base), and then annotate content with those URIs rather than free-text tags, leveraging content into Semantic Web, by linking data together. Moreover, tag meanings can be shared between people, providing an architecture of participation to define and exchange potential meanings of tags within a community of users.

Web Architecture Lab: HTTP/1.1 redrafting area

the question of whether there is a 'default' XML processing model, and if so what it looks like.