Développement Web

Quelques raccourcis :

Document en construction...

Mozilla a publié ce que cette firme nomme le « référentiel de compétences Web », un document listant ces aptitudes et compétences qu'elle estime nécessaires pour utiliser le Web de manière participative : https://webmaker.org/standard

Document généraliste sur l'évolution du Web : http://www.evolutionoftheweb.com/

La programmation Web est devenue bien trop complexe : http://en.arguman.org/web-programming-is-getting-unnecessarily-complicated

Ajax

L'approche Ajax, pour Asynchronous JavaScript and XML, permet de dynamiser les pages Web en réalisant des tâches asynchrones capables de modifier les éléments du DOM dynamiquement.

Un exemple simple de cette approche en JavaScript : JavaScript-Ajax.html

Pourquoi il est préférable d'utiliser XMLHttpRequest de manière asynchrone, un texte de 2011 : http://blogs.msdn.com/b/wer/archive/2011/08/03/why-you-should-use-xmlhttprequest-asynchronously.aspx

Un protocole de communication sur Ajax, à l'aide d'objets JSON : http://www.planbox.com/blog/news/updates/ajax-communication-protocol.html

Ajax et REST constitueraient un nouveau mirage architectural, selon William Vambenepe en 2011 : http://stage.vambenepe.com/archives/1801

Réaliser du Caching avec une application Ajax, proposition de Maxime Brazeilles en 2012 : http://fre.sc/tech-blog/a-new-approach-of-caching-in-web-applications

Applications et AppStores

L'AppStore d'Amazon serait pourri, selon ce texte de 2011 : http://shiftyjelly.wordpress.com/2011/08/02/amazon-app-store-rotten-to-the-core/

Architecture

Explication détaillée du fonctionnement d'un fureteur moderne, par Tali Garsiel en 2011 : http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/

Ce qui se passe vraiment quand on navigue vers une URL, par Igor Ostrovsky en 2011 : http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/

Réflexion écrite en 2010 par Carlos Bueno, chez Facebook, sur les considérations architecturales que doit comprendre un programmeur complet : http://www.facebook.com/note.php?note_id=461505383919&comments

Présentation de Chris Palmer qui explique que, dans une architecture pour le Web, on ne peut se passer du protocole https : http://assets.en.oreilly.com/...Presentation.pdf

En 2010, Skype est tombé en panne. Une explication du modèle architectural de Skype et de cette panne, par Dan York en 2010 : http://www.disruptivetelephony.com/2010/12/understanding-todays-skype-outage-explaining-supernodes.html

En 2011, ce fut au tour d'Amazon d'avoir une grosse panne : http://aws.amazon.com/fr/message/2329B7/

Comment quitter le Google App Engine si cet outil ne nous convient pas? Texte d'Eric Silverberg en 2011 : http://www-cs-students.stanford.edu/~silver/gae.html

Selon David Teller, en 2011, le modèle de développement Web est brisé, trop fragmenté en divers outils disparates : http://dutherenverseauborddelatable.wordpress.com/2011/04/18/rant-web-development-is-just-broken/

À propos de l'évolution rapide des plateformes Web, et de la difficulté pour les développeurs de suivre le tempo, par Scott M. Fulton III en 2011 : http://www.softwarequalityconnection.com/2011/05/will-the-next-web-platform-please-hold-still/

Le développement polyglote, texte de 2011 : http://blog.heroku.com/archives/2011/8/3/polyglot_platform/

En 2012, Neil McAllister réfléchit tout haut sur le Web en tant que plateforme avec Google Chrome et HTML5 : http://www.infoworld.com/d/application-development/google-chrome-html5-and-the-new-web-platform-186542

Réflexions sur les architectures Web modernes :

Pratiques architecturales :

Le Web adaptatif, par David Walsh en 2011 : http://www.i-com.net/blog/the-adaptive-web/

Plaidoyer pour les applications faites d'une seule page, incluant ce qu'on nomme maintenant le Infinite Scrolling, par Christian Heilmann en 2011 : http://christianheilmann.com/2011/12/28/on-single-page-apps/

En 2012, Joe Gregorio se questionne sur les raisons derrière la grande variété d'architectures Web pour Python : http://bitworking.org/news/Why_so_many_Python_web_frameworks

Questions de performances :

Gestion des états :

Lancer un nouveau site Web :

Certification

Il est parfois nécessaire de produire un certificat d'authentification et de signer une application Web pour que celle-ci soit jugée sécuritaire par des tiers.

L'un des principaux organismes de certification aux États-Unis est VeriSign : http://www.verisign.com/

HTML

Format de représentation de documents répandu s'il en est un.

HTML5

En quoi HTML5 se distingue-t-il de ses prédécesseurs? Une vision amusante. Plus sérieusement : http://dev.w3.org/html5/html4-differences/

Le standard HTML5, attendu depuis longtemps, est une avancée extrêmement significative dans le monde du développement Web. Fruit d'un long processus de maturation de plusieurs standards, et offrant des fonctionnalités qui rendent essentiellement obsolètes plusieurs autres technologies, dont Silverlight de Microsoft et Flash d'Adobe, ce nouveau standard semble voué à devenir le seul standard html à long terme, ayant été adopté à la fois par Microsoft et par Google.

Notez que malgré sa standardisation sur HTML5, le développement de html se poursuit et peut confondre à la fois développeurs et usagers. À ce propos, un article d'Ingrid Lunden en 2012 : http://techcrunch.com/2012/07/22/html5-work-splits-into-living-and-snapshot-standards-developers-need-not-standard/

Notez que dans les nombreux liens qui suivent, il est important de porter attention aux dates de publication puisque ce standard est en constante évolution, donc les critiques d'hier peuvent ne pas tenir aujourd'hui. Notez aussi qu'il est question de ne plus avoir de nouvelles versions de la norme html suite à HTML5, et de faire plutôt évoluer celle-ci, comme l'indique Jeffrey Zeldman en 2011 avec http://www.zeldman.com/2011/01/27/html5-vs-html/ ou encore le WHATWG lui-même à travers Ian Hickson en 2011, http://blog.whatwg.org/html-is-the-new-html5, ce qui implique que tout est en fluctuation.

En 2012, HTML5 est officiellement Feature-Complete sans être officiellement un standard :

Démarrer avec HTML5, un tutoriel proposé par Grace Walker :

Quel est le plus petit document HTML5 légal possible? Proposition de Chetan Jain en 2011 : http://dev.chetankjain.net/2011/12/minimal-required-code-in-html5.html

Caractéristiques du standard :

Technique :

Outils :

Critiques :

À propos des impacts de HTML5 :

Applications :

Développement

Quelques liens menant vers des articles sur la question du développement Web au sens large.

En 2012, Dean Michael Berris publie une courte mais pertinente série d'articles sur le processus de développement de son serveur http en C++, incluant ses efforts pour adapter les fruits ses efforts aux idiomes et pratiques de C++ 11, la gestion de l'adaptabilité et de la flexibilité attendues d'un tel outil, les difficultés rencontrées avec certaines tentatives d'inclure de la métaprogrammation, etc. :

Écrire une application Web avec Go : http://golang.org/doc/articles/wiki/

Écrire une application Web avec Racket, par Matthew Might en 2015 : http://matt.might.net/articles/low-level-web-in-racket/

À propos des applications monopages :

Texte intéressant de 2012 expliquant une technique par laquelle des onglets peuvent partager des ressources à l'intérieur d'un fureteur : http://blog.fastmail.fm/2012/11/26/inter-tab-communication-using-local-storage/

Selon Mathieu Fenniak en 2013, le temps est venu de cesser de produire des API fragiles pour le Web : http://mathieu.fenniak.net/stop-designing-fragile-web-apis/

Gérer l'évolution d'une API pour le Web, par Mark Nottingham en 2013 : http://www.mnot.net/blog/2013/06/23/linking_apis

DOM (Document Object Model)

À venir...

Exemple concret : Exemple--DOM.html

SAX (Simple API for XML)

À venir...

Exemple concret : Exemple--SAX.html

Idées et pratiques

Dans la section sur les antémémoires (mémoires Cache) de cette page sur l'optimisation, vous trouverez une section sur les antémémoires et les applications Web.

Introduire un parcours séquentiels dans un espace de lecture non-linéaire :

Comment faire pour livrer une page HTML à un fureteur sous forme de texte brut, pour ne pas qu'elle soit interprétée comme du HTML : http://perlpunks.de/deliver_html_as_text_plain.html

Comment développer une API de traitement de flux de données en Python, un exemple proposé par Josiah Carlson en 2011 : http://dr-josiah.blogspot.com/2011/05/essentials-behind-building-streaming.html

À propos des Content Farms, ces sites qui s'affichent sur les moteurs de recherche mais offrent du contenu de mauvaise qualité, ou même bidon :

À propos des hash-bangs (#!),

À propos de la validation des entrées :

Réflexions sur l'éthique et le partage du contenu dans Internet :

Il est possible de guider les crawlers à l'aide d'un fichier ROBOTS.TXT :

Déboguer les applications Web :

Optimiser les applications Web :

Tester les applications Web :

À propos du design Web :

À propos de la consommation en ligne :

À propos de la « Linuxification » des applications Web, texte de 2011 : http://notes.deaxon.com/linuxification-of-webapps/

Vaut-il la peine de construire son propre système de cartographie à l'ère de Google Maps? Selon Sébastian Delmont, en 2012, la réponse peut être oui : https://plus.google.com/u/0/118383351194421484817/posts/foj5A1fURGt

À propos de la saine gestion des tâches asynchrones dans un fureteur, un texte de 2012 : http://blog.mozilla.org/tglek/2012/04/18/web-2-0-a-collection-of-settimeouts/

Amener au Web la mécanique des intentions (Web Intents), mise de l'avant par Google pour Android. Proposition soumise en 2012 : http://dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html

Applications Web et codes d'erreur, texte de Bruno Pedro en 2013 : http://apiux.com/2013/03/28/2-steps-api-error-codes/

A-t-on besoin d'un bytecode dans nos fureteurs? Ce bytecode serait-il JavaScript? Un texte d'Alon Zakai en 2013 : http://mozakai.blogspot.de/2013/05/the-elusive-universal-web-bytecode.html

Quoi faire pour conserver le concept de HTTP Referrer même si on a recours à https? Un texte de Stephen Merity en 2013 : http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html

Les applications Web sont-elles vraiment le futur? Texte d'opinion de Nick Heath en 2013 : http://www.zdnet.com/web-apps-the-future-of-the-internet-or-an-impossible-dream-7000019320/

Infonuagique (Cloud Computing)

À propos de la croissance des données hyperliées au fil des années, par Alex Williams en 2011 : http://www.readwriteweb.com/cloud/2011/01/the-concept-of-linked-data.php

L'année 2015 sera celle du Zettabyte de données, selon Sanjeev Ramachandran en 2011 : http://www.devicemag.com/2011/06/24/zettabytes-coming-of-age-we-know-you-are-wondering-what-they-are/

Marché

L'approche SaaS, ou Software as a Service, permet à un usager de louer un service en fonction de diverses modalités de paiement.

En 2012, Sasha Greif discute des risques d'atteindre un niveau de saturation dans ce modèle, à force de tirer des sous ici et là des usagers :

Texte d'Alex Payne en 2012 expliquant comment ne pas vendre du logiciel : http://al3x.net/2012/02/29/how-not-to-sell-software-in-2012.html

Selon Rachel Andrew en 2012, il ne vaut plus la peine de se créer des problèmes en supportant des fureteurs trop anciens comme IE6 ou IE7 (et même IE8, selon elle...) : http://www.rachelandrew.co.uk/archives/2012/03/21/stop-solving-problems-you-dont-yet-have/ (notez qu'elle n'insiste pas sur les versions de Firefox, Chrome ou Opera car leurs utilisateurs tendent à se tenir un peu plus à jour).

Réflexion de Trey Smith en 2012 sur la chute d'Angry Birds et l'impact des jeux gratuits sur le marché : http://www.treysmithblog.com/the-fall-of-angry-birds/

Internationalisation et localisation :

Mashups

L'organisation OpenMashup.org, qui vise à augmenter l'interopérabilité des composants sur le Web : http://www.openmashup.org/

Network Address Translation (NAT)

Contourner les contraintes d'un NAT? L'outil pwnat : http://samy.pl/pwnat/

Nommage

Dans le monde des services répartis, on trouve plusieurs approches au nommage unique des ressources (des objets, des entités, des services, etc.). Certaines sont universelles, d'autres sont associées de plus près au monde du Web.

URI

Une URI, pour Uniform Resource Identifier, est une manière d'identifier de façon unique toute ressource. En gros, il s'agit d'un chapiteau regroupant à la fois les URL et les URN.

Pour en savoir plus :

URL

Une URL, pour Uniform Resource Locator, est un descriptif du chemin menant vers une ressource, de manière non-ambiguë. En prenant pour exemple la forme la plus connue, soit celle associée au protocole http, elle se compose :

Pour atteindre de manière inéquivoque la section URL que vous lisez présentement, l'URL est donc http://h-deb.clg.qc.ca:80/Sujets/Web/Developpement-Web.html#url (mais le port, :80, est optionnel puisque c'est le port par défaut pour le protocole http).

Pédagogie :

Pour en savoir plus :

URN

Une URN, pour Uniform Resource Name, est un nom qui se veut persistant et sans ambiguïté pour identifier une ressource. Un URN est indépendant du lieu où est entreposé une ressource, alors qu'une URL est directement associée à un lieu.

Les URN suivent la forme urn:NID:NSS NID est un espace nommé et NSS est une chaîne de caractères soumise à des règles qui varient selon les espaces nommés. Le jeton urn, préfixe dans cette notation, est insensible à la casse.

Pour en savoir plus :

Outils

Plusieurs outils (plusieurs d'entre eux gratuits!) existent pour aider au développement pour le Web. En voici quelques-uns :

Questions d'ordre général :

Silverlight

Technologie de Microsoft (du côté du code ouvert, l'équipe derrière Mono avait aussi échafaudé Moonlight, un équivalent compatible en grande partie) pour dynamiser le volet client des applications Web à même les outils et langages de la plateforme .NET.

Quelques liens pédagogiques suivent :

Portez attention à la chronologie, car en 2012, l'avenir de cette technologie ne semble pas très rose.

Quelques liens d'ordre général sur le sujet :

Protocoles

Le monde du Web et des systèmes répartis est bâti en entier sur un ensemble de protocoles. Vous trouverez ci-dessous un ensemble (non-exhaustif) de sections portant sur certains des plus importants d'entre eux.

Protocole http

Le protocole http, pour Hypertext Transfer Protocol, est fort simple. Composé essentiellement de deux commandes principales, GET et POST, il vise à faciliter le transfert de fichiers entre un client et un serveur, ce dernier étant normalement (mais pas nécessairement) lié au port 80.

Le protocole http repose sur les fondations du couple TCP/IP, ce qui implique l'envoi de flux de données entre le client et le serveur. Une trame http est composée d'un en-tête informatif et d'un corps contenant essentiellement le document transmis.

L'en-tête d'une trame http indique quelques données quant à la nature du document contenu dans le corps de la trame, incluant la taille en bytes de ce document . Le document peut être à peu près n'importe quoi, comme on peut le constater en furetant dans Internet.

De par sa simplicité, de par son ubiquité sur Internet , et parce qu'il sert essentiellement à transférer des documents, le protocole http sert fréquemment de support aux protocoles client/ serveur modernes. Ces protocoles profitent de l'ouverture reconnue à http et s'en servent comme protocole de transport en décrivant à la fois leurs requêtes et leurs réponses sous forme de documents XML.

Le protocole http est un simple protocole de transfert de documents. Les serveurs Web communiquent naturellement à l'aide de ce protocole (entre autres), mais il est relativement simple de développer un système transigeant des trames http.

Une trame http est faite d'un en-tête et d'un corps (aussi nommé Payload). L'en-tête peut contenir un vaste éventail de données descriptives, incluant la version de http utilisée, la taille du corps, le comportement des homologues quant au maintien de la connexion, la technologie et la plateforme de l'émetteur, la langue du fureteur ou du document contenu dans la trame, le type de contenu, etc.

Caractéristique importante de http : il s'agit d'un protocole sans état. C'est là à la fois une des raisons de son succès et la source de divers maux de tête chez les gens développant des systèmes ou transactionnels reposant sur ce protocole. En effet, un protocole sans état ne présume pas que les homologues demeurent connectés l'un à l'autre entre deux échanges, et n'exige pas du code serveur qu'il maintienne une représentation de l'état de ses échanges avec son client. Cela implique qu'une trame http doit être pleinement autodescriptive. Le client est responsable de faire suivre, par exemple à travers les paramètres apposés à la fin de l'URL indiquant le lieu du serveur ou à partir de données sessions telles celles entreposées dans des témoins, la totalité des états pertinents à la description de l'état courant de ses échanges avec le serveur.

Le bon côté des protocoles sans état est qu'ils sont fortement échelonnables (il s'agit d'un néologisme mais c'est-ce que j'ai trouvé de mieux pour l'anglais Scalable). En effet, en laissant reposer le poids de la conservation des états transactionnels du côté client, les protocoles sans état permettent la conception de serveurs moins sujets à être écrasés en période de pointe par une masse trop importante de clients.

Les protocoles sans état facilitent aussi la mise en place de procédures pour remplacer dynamiquement un serveur déficient ou sujet à une période d'entretien : puisque chaque requête provenant d'un client est autonome et pleinement autodescriptive, il est possible de mettre en place un groupe de serveurs tels que les uns soient aussi qualifiés que les autres pour traiter n'importe quelle requête.

Une requête http débute par le type de commande (souvent GET ou POST) suivi d'une gamme de paramètres descriptifs (nom de domaine du serveur, version de http utilisée, document demandé dans le cas d'une requête GET, langue, etc.). Une réponse http débute par un code de succès ou d'erreur, suivi d'un ensemble de données descriptives (langue, encodage, taille du corps du message, etc.). Le code de succès typique pour un GET ou un POST est 200, et l'erreur la plus fréquemment rencontrée par un fureteur est sans doute l'erreur 404 (le document spécifié par la requête est introuvable).

Une requête GET permet à un client de demander à un serveur l'information correspondant à l'URI de la requête, URI susceptible d'être une URL suivie de paramètres. Cette information peut être un document existant ou généré par programmation.

L'en-tête d'une trame http pour une requête GET peut contenir de l'information ayant pour but de guider la réaction du serveur suite à l'analyse des paramètres (l'équivalent d'alternatives en fonction de la présence ou de l'absence de certains paramètres, par exemple). D'un point de vue performance, les requêtes GET peuvent être placées en antémémoire dans le fureteur si certaines conditions sont respectées. D'un point de vue sécurité, le fait que les paramètres d'une requête GET apparaissent dans l'URI rend ce type de requête vulnérable à une interception par un tiers hostile. Pour en savoir plus, mieux vaut consulter la documentation du protocole.

Une requête POST est le moyen privilégié de soumettre à un serveur des données potentiellement sensibles à partir d'un poste client. Les divers champs d'une requête POST sont imbriqués dans le contenu du message plutêt que dans l'URI de destination. En retour, la plupart des clients n'entreposent pas les requêtes POST en antémémoire.

À propos de http 2.0 :

À propos des verbes PUT et POST, un texte de Philip Potter en 2011 : http://rhebus.posterous.com/put-vs-post

De nouveaux codes d'états pour http, un RFC de 2011 : https://tools.ietf.org/html/draft-nottingham-http-new-status-02

Réflexion d'Armin Conacher, en 2012, sur le design d'une API efficace pour exploiter http : http://lucumr.pocoo.org/2012/4/14/im-doing-http-wrong/

Le protocole http du point de vue d'un programmeur, par Scott Allen en 2012 : http://odetocode.com/Articles/741.aspx

Devrait-on utiliser OPTIONS dans le protocole http? Pas vraiment, selon Mark Nottingham en 2012 : http://www.mnot.net/blog/2012/10/29/NO_OPTIONS

Faire évoluer une API basée sur http, par Mark Nottingham en 2012 : http://www.mnot.net/blog/2012/12/04/api-evolution

Critiques :

Codes d'erreur

Les codes de résultat (erreur ou succès) de http sont connus et documentés, du célèbre 404 (File not found) au 200 (Ok) en passant par plusieurs autres.

Protocole https

Le protocole http transfère des documents en clair. Pour sécuriser en partie les échanges sur le Web, en particulier lors de transactions électroniques, mais aussi pour une variété d'échanges impliquant le transfert de données personnelles un « sensibles », ajouter une strate de chiffrement aux communications est nécessaire. C'est ce qu'offre le protocole https.

En 2010, Chris Palmer explique comment déployer https correctement : https://www.eff.org/https-everywhere/deploying-https

Vivre (correctement) avec https, un texte d'Adam Langley en 2012 : http://www.imperialviolet.org/2012/07/19/hope9talk.html

En 2012, Valentin Golev nous demande si nous prenons soin de vérifier les certificats https côté client : http://unfoldthat.com/2012/07/30/does-https-to-api-make-any-sense.html

Dans ce texte de 2011, Dave Ward explique pourquoi il est important qu'une page sécurisée ne réfère qu'à d'autres contenus sécurisés. Il suffit d'un seul accès non-chiffré pour tout gâcher : http://encosia.com/cripple-the-google-cdns-caching-with-a-single-character/

Comprendre le fonctionnement de https, texte de Hartley Brody en 2013 : http://blog.hartleybrody.com/https-certificates/

Protocole JSON

Le terme JSON signifie JavaScript Object Notation. Il s'agit d'un format facilitant grandement la représentation des structures de données relativement simples qu'on rencontre par exemple dans les échanges RPC, surtout en comparaison avec la complexité des formats XML.

Vous trouverez plusieurs liens thématiques sur le sujet, de même que des exemples d'utilisation de ce format, sur JSON.html

Protocole sftp

Tout comme https permet de sécuriser en partie les échanges http, le protocole sftp est (grossièrement) une sorte de pendant ssh de ftp.

Comment faire en sorte que les échanges sftp soient rapides, selon Daniel Stenberg en 2010 : http://daniel.haxx.se/blog/2010/12/08/making-sftp-transfers-fast/

L'approche REST

L'approche REST, pour Representational State Transfer, est le fruit des travaux de Roy Fielding, décrit dans sa thèse de 2000 que vous pouvez consulter sur http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm. À cet effet, quelques liens.

Généralités et pédagogie :

Technique et design :

Critiques :

Serveurs Web

Le serveur Apache Axis 2 : http://axis.apache.org/axis2/java/core/

Le fichier de configuration d'Apache, un texte de 2011 : http://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art004

Configurer un serveur Web robuste et sécuritaire, par Lee Hutchinson en 2012 : http://arstechnica.com/gadgets/2012/11/how-to-set-up-a-safe-and-secure-web-server/

Écrire un serveur Web avec Python, série d'articles par Ruslan Spivak en 2015 :

Pour un guide au Web Hosting, donc pour savoir comment amener votre site Web à la disposition des gens, les gens derrière http://www.whoishostingthis.com/resources/web-hosting/ m'ont proposé leur site. Ça m'a semblé pas si mal alors voilà.

La bibliothèque Ponyo, pour écrire des serveurs Web en ML : http://ponyo.org/handbook/ponyo-basics/3

Services Web

En 2011, Gary Shutler explique son approche à la conception de services Web : http://www.robustsoftware.co.uk/post/3163820769/pragmatic-web-service-design

Témoignage en 2011 de Robert Laing, chef d'entreprise, qui relate une liste des services Web auxquels a recours son entreprise quotidiennement : http://mygengo.com/about-us/blog/15-web-services-we-rely-on-every-day/

L'outil Wolfram Alpha, si chic soit-il, n'est pas un service Web destiné aux programmes, comme l'a constaté une entreprise en 2011 : http://blog.agiletortoise.com/post/3564424414/wolfram-alpha-doesnt-get-it (les choses ont – un peu – changé depuis : http://blog.agiletortoise.com/post/3587122629/wolfram-listens-and-changes-policy-but-not-tos).

Quels seraient les avantages et les inconvénients d'offrir des services Web immuables? Une réflexion de Bruce Hauman en 2013 : http://rigsomelight.com/2013/06/17/immutable-data-service.html

Que sont les Amazon Web Services (AWS)? https://www.expeditedssl.com/aws-in-plain-english

Travailler avec JAX-WS, par Upendra Chintala en 2012 :

Parmi les protocoles les plus répandus pour faire interopérer deux homologues à partir de services Web, on trouve en particulier :

Les services Web peuvent en théorie être répertoriés dans des annuaires UDDI, pour Universal Description Discovery and Integration. En pratique, ce « rêve » n'a pas été réalisé, mais bon, ça arrive. Pour en savoir plus :

On me demande souvent de livrer quelques services Web commerciaux avec lesquels il seraitr possible d'interfacer pour expérimenter.

Voici une courte liste comprenant des services que des étudiant(e)s m'ont suggéré au fil des sessions :

Vous trouverez aussi des exemples dans la section décrivant le format WSDL. N'hésitez pas à m'en suggérer d'autres!

Je vous recommande ce texte de 2015 par Martin Fowler sur les saines pratiques lorsque l'on interface avec une API externe sur le Web, en particulier une API de Google. Le texte comprend des exemples et une réflexion sur les façons de faire : http://martinfowler.com/articles/refactoring-external-service.html

Java et les services Web :

En 2016, Iris Classon démontre comment il est possible de développer en quelques minutes un client capable de consommer une API de données météo avec C# : http://irisclasson.com/2016/11/24/weather-api-in-five-minutes/

Écrire un service Web avec bash, par Henry Snopek en 2017 : https://hackernoon.com/a-web-service-written-in-pure-bash-2af847902df1

Microservices

Certains tendent vers les microservices, soit des services qui font une seule chose mais la font bien. À ce sujet :

Témoins (Cookies)

Un témoin est une unité d'entreposage côté client dans une relation client/ serveur sur le Web. Chaque témoin est associé à une URL d'origine; plusieurs témoins peuvent être associés à une même URL; les témoins sont locaux à chaque fureteur (donc si vous réalisez une transaction électronique impliquant des témoins avec un fureteur, il est probable qu'un autre fureteur sur le même ordinateur n'en sache rien). Un témoin ne peut contenir que de petites quantités d'information (4 Ko maximum).

Un Wiki sur le sujet : http://en.wikipedia.org/wiki/HTTP_cookie

Un exemple simple de manipulation de témoins avec du code JavaScript : JavaScript-Temoin.html

Une réflexion sur les risques inhérents au recours à des témoins, par Jeff Atwood en 2010 : http://www.codinghorror.com/blog/2010/11/breaking-the-webs-cookie-jar.html

L'API nommée evercookie pour JavaScript, qui permet de créer des témoins extrêmement persistants : http://samy.pl/evercookie/

Les témoins zombies, qui ne veulent pas mourir : http://www.infoworld.com/t/internet-privacy/zombie-cookies-wont-die-microsoft-admits-use-and-html5-looms-new-vector-170511

Des témoins persistants et impossibles à bloquer, à l'aide des en-têtes http, par Nik Cubrilovic en 2011 : http://nikcub.appspot.com/persistant-and-unblockable-cookies-using-http-headers

En 2011, Microsoft a cessé d'utiliser des « super témoins » dans MSN :

Un bogue fondamental des témoins : ils ne connaissent pas leur origine. Texte d'Egor Homakov en 2013 : http://homakov.blogspot.com.es/2013/07/core-flaw-of-cookies.html

Simuler des témoins... sans témoins, et compromettre la vie privée des gens. Texte de 2013 : http://lucb1e.com/rp/cookielesscookies/

WebRTC

Une technologie destinée à permettre une communication audiovisuelle en « temps réel » à travers le Web, et reposant strictement sur une API accessible par JavaScript.

Websockets

Les Websockets permettent à un client Web de transiger avec le reste du monde de manière bidirectionnelle à travers TCP.

Un Wiki sur le sujet : http://en.wikipedia.org/wiki/WebSockets

Un site proposant des exemples de code de Websockets : http://websocket.us/

Le RFC 6455, qui officialise en 2011 le protocole des Websockets : http://www.ietf.org/mail-archive/web/ietf-announce/current/msg09663.html (le RFC lui-même est http://www.rfc-editor.org/rfc/rfc6455.txt)

Utiliser les Websockets avec Clojure, selon Jay Field en 2011 : http://blog.jayfields.com/2011/02/clojure-web-socket-introduction.html

Un descriptif du Code Project, texte de 2011 par Wayne Ye : http://www.codeproject.com/KB/HTML/Web-Socket-in-Essence.aspx

Les performances des Websockets, par Drew Harry en 2011 : http://drewww.github.com/socket.io-benchmarking/

En 2011, Bruce Eckel expérimente avec les Websockets à l'aide de Python et de CoffeeScript : http://www.artima.com/weblogs/viewpost.jsp?thread=339100

Écrire un SCS avec Websockets en Scala, un texte de Jean-François Arcand en 2012 : http://jfarcand.wordpress.com/2012/02/10/writing-clientserver-websocket-application-using-scala/

Exemple de SCS d'écho à l'aide de Websockets, texte de 2012 par Brian Raymor : http://www.sitepoint.com/websockets-stable-and-ready-for-developers/

Textes de John McCutchan :

Java 7 version EE et les Websockets, un texte d'Arun Gupta en 2012 : https://blogs.oracle.com/arungupta/entry/websockets_and_java_ee_7

Un « Websockets 101 » proposé par Armin Ronacher en 2012 : http://lucumr.pocoo.org/2012/9/24/websockets-101/

Un daemon de Websocket : http://websocketd.com/

Le projet Seasocks, Un serveur de Websockets pour C++, par Matt Godbolt en 2015 : http://xania.org/201503/seasocks-an-embedded-websocket-server-for-c-plus-plus

Reconnecter un Websocket en temps réel... sans noyer le serveur, par John Ryding en 2014 : http://blog.johnryding.com/post/78544969349/how-to-reconnect-web-sockets-in-a-realtime-web-app

Les Websockets en Ruby à partir de rien, un pas à pas par Jamie Patel en 2015 : https://blog.pusher.com/websockets-from-scratch/

Les Websockets expliqués par Dmitriy Rogatkin en 2015 : http://www.infoq.com/articles/websocket-desktop-agility-web-applications

En 2015, Sam Saffron rappelle qu'il n'y a rien de simple aux Websockets : https://samsaffron.com/archive/2015/12/29/websockets-caution-required

Écrire un serveur de Websockets en Go, par eli Bendersky en 2016 : http://eli.thegreenplace.net/2016/go-websocket-server-sample/

Visualiser les paquets sur des Websockets, par James Hague en 2016 : http://prog21.dadgum.com/225.html

Web Workers

Les Web Workers dynamisent le code exécuté côté client sur une page Web, se comportant comme des tâches soumises à un thread pool.

Petite introduction aux Web Workers, par Brian Cooksey en 2013 : https://zapier.com/engineering/intro-to-web-workers/


Valid XHTML 1.0 Transitional

CSS Valide !