PUBLIC MARKS with tag webarch

There has been a lot of frustration lately about layered systems in computer science and especially the Web.

As with anything, there are downsides to using this technique. The main one being no more interactivity. If your website had a commenting feature built in, it won’t work anymore. If it ran off a CMS like WordPress, you won’t be able to log in and make edits to your content. Everything is now static HTML, forever.

So, we developed a don't-ask/don't-tell policy of making private copies of documents and carrying them around with us. Engineers, to generalize, hate waiting around for stupid reasons, and having documents meant that we could get to work. It also made us look better, since we got things done on time, instead of having to send out lame excuses that we're late because we're waiting on a fax.

They estimate Amazon would cost them 4 times much.

Sur le Web, il y a une tendance à oublier ou négliger les archives.

RESTful web services are one of our core design patterns. Fielding’s thesis identifies four major constraints that identify a RESTful architecture (statelessness, resource-orientation, uniform interface, hypermedia-driven application state). Many “RESTful” APIs only get 3 out of 4 of these; we’ve begun experimenting with using XHTML as a media type for our APIs, and this provides a lot of power in terms of scalability and loose coupling between client and server.

Persistence — only mint a new URIs if one doesn’t already exist: once minted, never delete it

Forever is the length of a single, human life.

MIME was invented originally for email, based on general principles of 'messaging', foundational architecture. The role of MIME was to extend Internet messaging from ASCII-only plain text (other character sets, images, rich documents, etc.) The basic architecture of complex content messaging is:

the essential idea of their API is quite simple and familiar: every major kind of data resource has a bookmarkable Web address, and the document found at that URL can have a structure suited to its content and links to related resources.

karl says:

March 2, 2010 at 11:07 am

In your paragraph

“one of the axioms of the web that URIs are opaque, and that machines “should not look at the contents of the URI string to gain other information”, but there are lots of ways in which humans don’t follow this principle”

Not only humans in fact. The first item in your list is talking about Google and it has changed a lot the way the Web is made. In commercial environments (aka Web Agencies), SEO (capacity of having a better findability) touches the content organization but also the words in URIs. So often the SEO person will not only recommend the way to architect content in the page, but also the words that must be in the URI. It is basically an additional constraint to the list you created.

* Persistence

* Readability

* Findability

Commentaire obligatoire : je ne suis pas archiviste ;)

Dans le domaine des archives traditionnelles de l'objet matériel, il me semble qu'un des points importants est la duplication : C'est à dire la reproduction à l'identique d'un objet en de nombreux endroits. Cette duplication créé des contraintes (stockage, duplication du travail parfois), mais elle assure aussi une certaine forme de pérennité (réduction de la fragilité, indépendance entre le lieu de l'objet physique et de sa référence dans le modèle).

En revanche le Web propose un identifiant mais pour une copie unique très souvent d'un contenu, ce qui est pratique mais aussi fragile. L'URI en tant qu'identifiant seul et indépendant de sa localisation n'est pas rentré dans les mœurs.

L'autre enjeu aussi est que l'archive Web est un processus continu. Le contenu peut changer en permanence pour un identifiant donné (ce qui a un effet de bord très intéressant sur les lois de protection des contenus.)

Le contenu actuel des bibliothèques peut être rendu disponible et une même œuvre peut avoir plusieurs URIs de localisation et un URI unique d'identification. Et même si celui ci n'est pas unique, ce n'est pas si grave owl:sameAs est là pour cela. Mettre à disposition d'abord et recoller ensuite les morceaux, car le fait que la contrainte de l'espace physique n'existe plus en ligne, le tube de colle est également plus facile à utiliser. Mais j'ai une vue qui est peut-être trop pragmatique.

2 janvier, 2010 - 21:49 — karl

It's also possible to create some APIs that would tell a website how much bandwidth is available to it, so the developer could adjust its features accordingly. This idea is being tossed around between web companies and operators, but I don't know how much is actually being done about it.

What is the guiding principle to make an informed design decision regarding the direction of communication in such a replication scenario? The answer is separation of concerns with the goal of simplicity and avoiding unnecessary coupling. This leads to the question which of the systems should for which communication play the server role and which one should play the client role?

karl Says:

novembre 28th, 2009 at 10:15

REST est un style architectural qui est encore une couche au dessus de HTTP.

Je rejoins Christian dans son analyse. Chacun des domaines est d’ailleurs interprété en fonction de la culture propre des intervenants. Lorsque l’on SPDY de Google qui est une forme d’extension à HTTP. Ils ne s’intéressent proprement dit qu’à l’efficacité du transport et pratiquement pas à l’amélioration du transfert.

Google centralise tous les services dans une même coquille. Sa seule interaction au final n’est avec qu’avec les logiciels clients. L’interopérabilité avec les autres serveurs n’est presque pas un objectif à terme. Ils ont besoin de rapidité, ils ont des besoins spécifiques qu’ils maîtrisent au cœur de leurs applications. Lorsqu’on a créé un écosystème avec un fort contrôle sur tous les éléments du système, on peut se permettre d’imposer sa loi à l’écosystème. Microsoft l’a fait dans l’univers de la bureautique. Google le fait petit à petit pour le Web. Nous n’y sommes pas encore bien sûr.

Pour Google, le transfert n’est pas important ou plutôt il est si peu mis en pratique (quid de HTTP PUT, DELETE, etc., des mime types et des headers) sur le Web aujourd’hui, que Google peut se concentrer sur ce qui améliore le transport des données.

15karl

@chaals

I had written something these lines a few years ago… Sorry it is in French.

http://www.la-grange.net/2006/04/14 - Un commentaire de trop

But somehow it is a distributed architecture around comments and blogs. If we really think about it a comment, a blog post, and a tweet have the same features usually.

an author, a url (or url-fragment), a text, a date.

blog posts have usually in addition a title and sometimes categories.

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.

So, in a nutshell, here is a tick-list for an architecture for participation:

* Open Source Implementations

* Test Suites

* Continuous Integration

* Wiki Driven Documentation

* Small, Lightweight Specifications

* Free and Open Licensing

I've published a manifesto for this approach in the form of a gnomic sampler on http://standeace.com, a contraction of "Standards" and "Peace":

Designing your Product as a Platform

WebAccessControl is a decentralized system for allowing different users and groups various forms of access to resources, where users and groups are identified by HTTP URIs.

Once freed from the awkward initial step of building their own base map, non-specialists rapidly colonized the online mapping space.

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.