"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Architecture logicielle web avec Ajax/REST, HTTP

Posted by patrick sur février 6, 2007

Source: http://www-128.ibm.com/developerworks/xml/library/wa-ajaxarch/

J’ai découvert l’architecture REST en lisant l’excellent livre de Christophe Porteneuve « Bien développer pour le Web 2.0 ». Je continue d’approfondir mes connaissances sur ce sujet en lisant cet article.

Immersive Web applications are certainly useful, but the server-side immersive Web application style is in fundamental disharmony with REST architectural principles. Specifically, it violates a key REST constraint and fails to take advantage of one of REST’s most important advantages, thereby spawning a new set of problems. REST’s « client-stateless-server » constraint forbids session state on the server. Designing within this constraint promotes the system properties of visibility, reliability, and scalability. But immersive server-side Web applications wish to provide a great deal of personalization to a single user, so they must choose between two designs. The first is to send a massive amount of state information with each client request, so that each request is context-complete and the server can remain stateless. A second, ostensibly simpler, solution favored by application developers and middleware vendors alike is to send a simple user identity token and associate this token with a « user session » object on the server side. The second design directly violates the client-stateless-server constraint. It certainly enables desirable user functionality (especially personalization), but it places tremendous strain on the architecture. ava™ Servlet’s HttpSession API provides an example of this strain. HttpSession lets you associate session state with a particular user. This API seems deceptively simple to novice developers. Indeed, it appears that you can store any object in HttpSession and pull it out without ever coding any special lookup logic yourself. But as you start putting more objects in HttpSession, you start to notice that your application server uses more and more memory and processing resources. Soon you decide that you need to deploy your application in a clustered environment to help with growing resource needs. Then you realize that for HttpSession to work in a clustered environment, each object must implement Java’s Serializable interface so that session data can be transmitted between servers in a clustered environment. Then you must decide whether or not your application server should persist session data in the case of a shutdown/restart cycle. Soon you begin to question whether violating the client-stateless-server constraint was such a good idea after all. (Actually, many developers are ignorant of this constraint.)

But why centralize so much resource consumption on an overburdened server, when in theory you could distribute processing and memory needs to clients? The simple answer is that given traditional Web browser constraints, this wasn’t feasible (see Client-side processing without Ajax). But the Ajax architectural style lets developers distribute processing and state requirements to the client. Read on to learn why immersive applications that choose an Ajax-style architecture can regain harmony with REST and enjoy its benefits.

….

The Dojo Toolkit is a good example (see Resources). Dojo provides build-time tools to create a compressed JavaScript file containing all of your application’s logic, presentation, and styles. Because it’s ultimately just a file, a Web browser can cache it, meaning that the second time you visit a Dojo-enabled Web application, you’re likely loading the Ajax engine from your browser’s cache rather than from the server. Compare this to a highly immersive server-side Web application where every request results in significant server processing because your browser and network intermediaries can’t cache the ever-changing resources.

….

What about the business data? Because the application logic and state reside and execute on the browser, the application’s interaction with the server becomes very different from that of a traditional Web application. Instead of fetching amalgamated pages of content, it simply needs to fetch business data.

Another benefit of the Ajax architectural style is the ability to deal easily with server failure. As I mentioned before, server-side Web applications with immersive user experiences tend to hold large amounts of user session state on the server. If a server fails, the session state goes away and users experience odd browser behavior (« Why am I back to the home page? And where are the items in my shopping cart? »). In an Ajax application with a stateful client and stateless services, a server crash/restart can be completely transparent to the user because the server crash can’t affect session state, which lives in the user’s browser; a stateless service’s behavior is idempotent and determined solely by the content of user requests.

Rappel (http://fr.wikipedia.org/wiki/REST) :
REST (Representational state transfer) est une manière de construire une application pour les systèmes distribués comme le World Wide Web. Le terme a été inventé par Roy Fielding.

REST n’est pas un protocole ou un format, c’est une architecture, c’est l’architecture originale du Web, bâtie sur quelques principes simples :

  • l’URI est important : connaître l’URI doit suffire pour accéder à la ressource;
  • HTTP fournit toutes les opérations nécessaires (GET, POST, PUT et DELETE, essentiellement);
  • chaque opération est auto-suffisante : il n’y a pas d’état;
  • utilisation des standards hypermedia : HTML ou XML qui permettent de faire des liens vers d’autres ressources et d’assurer ainsi la navigation dans l’application REST.

Cette architecture n’est pas limitée à la réalisation d’application pour un utilisateur humain. Elle est de plus en plus utilisée pour la réalisation de services Web destinés à la communication entre machines. Dans ce cadre là, les requêtes et les réponses sont typiquement encodées en XML. REST dans ce cas là se pose en alternative à RPC et SOAP, alternative censée être plus simple à mettre en œuvre. Les systèmes qui suivent les principes REST de Fielding sont souvent appelés RESTful.

La thèse de Roy Fielding précise les avantages de cette architecture par rapport à d’autres architectures d’applications web. Citons entres autres :

  • L’absence d’état sur le serveur conduit à une consommation de mémoire inférieure et donc à une capacité plus grande de répondre à un grand nombre de requêtes simultanées.
  • L’absence d’état sur le serveur rend le fonctionnement plus simple à appréhender. Le résultat d’une requête ne dépend pas de variables cachées difficilement identifiables. Cela conduit à une mise au point plus simple.
  • L’absence d’état serveur permet une répartition des requêtes sur plusieurs serveurs avec une meilleure granularité et de manière plus souple. Cela permet aussi une meilleure tolérance aux pannes d’un des serveurs.
  • Le respect de la philosophie du protocole HTTP, à la différence de SOAP conduit à une architecture plus cohérente et plus simple.
  • l’utilisation d’URI comme représentant d’une ressource, permet la mise en place de serveurs cache.

http://tools.ietf.org/html/rfc2616  (« 9 Method Definitions ……………………………………..51

   9.1   Safe and Idempotent Methods .................................51
   9.1.1    Safe Methods .............................................51
   9.1.2    Idempotent Methods .......................................51
   9.2   OPTIONS .....................................................52
   9.3   GET .........................................................53
   9.4   HEAD ........................................................54
   9.5   POST ........................................................54
   9.6   PUT .........................................................55
   9.7   DELETE ......................................................56
   9.8   TRACE .......................................................56
   9.9   CONNECT .....................................................57)")

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

 
%d blogueurs aiment cette page :