Gargl - Créer des API à partir de n'importe quel site web. Gargl – Créer des API à partir de n’importe quel site web Attention, les amis, je crois que je tiens l'outil de la semaine.
Ça s'appelle Gargl et ça va faire des ravages. Gargl se compose d'une extension Chrome qui permet de tracer les appels faits sur les pages web, de les modifier légèrement pour les standardiser puis avec un générateur, de produire du code Java, JavaScript ou PowerShell qui fera office de connecteur API. Et comme une bonne vidéo vaut tous les bons discours du monde, je vous invite si vous êtes curieux à couper le son de la vidéo ci-dessous et à la regarder en plein écran.
Vous allez vite comprendre l'intérêt de la chose. Eh oui, Gargl permet de forger du code pour vos projets afin d'exploiter n'importe quel site et par extension les données qu'il contient. Attention toutefois, si vous n'avez pas l'autorisation du propriétaire du site, c'est limite. Photo sous licence CC Zigazou Vous avez aimé cet article ?
Les nouvelles architectures front Web et leur impact sur la DSI – partie 2. Dans la partie 1 de cet article, nous avons traité des nouvelles architectures front-end basées sur des applications Web massivement Javascript appelant des API offertes par un serveur back-end : les nouvelles architectures front Web et leur impact sur les DSI – Partie 1.
Nous avons vu qu’elles sont apparues ces dernières années grâce à l’augmentation des performances des navigateurs et à l’amélioration des outils d’industrialisation des développements Javascript. Dans cette seconde partie, nous nous intéresserons aux raisons pour lesquelles on devrait choisir ces nouvelles architectures, aux opportunités qu’elles offrent, et aux conséquences sur les organisations des directions informatiques.
Pourquoi utiliser ces nouvelles archis? Pour mutualiser le code back-end pour de multiples clients. Éléments pour la conception des APIs Hypermédias. L’article sur Web APIs 101 se terminait en disant que les démarches de conception d’APIs pouvait alors seulement commencer.
J’ai pensé qu’une précision sur les éléments de conception des APIs Hypermedia serait utile. Ressources, Représentations & Etats applicatifs HTTP est un protocole de transfert applicatif qui se différencie des autres protocoles de transfert en ce qu’il distingue les Ressources des Représentations. Cette couche d’abstraction supérieure (la ressource) justifie pleinement l’expression de Tim Berners Lee selon laquelle les questions d’architecture du Web peuvent être qualifiées de “philosophical Engineering”. Architectures logicielles et APIs Hypermédias. Concevoir une architecture hypermedia distribuée requiert de se placer dans une perspective très simple où c’est l’échange entre le serveur et le client qui focalise les décisions d’architecture.
En l’occurence, si l’on parle d’APIs Web, cela suppose une bonne connaissance de HTTP d’une part, et une bonne connaissance des MediaTypes qui seront utilisés d’autre part. Cela veut dire qu’il faut se focaliser sur les messages que s’échangent le client et le serveur. Ce que le client ou le serveur font par ailleurs de ces messages échangés est secondaire. H Factor : Hypermedia Types. The H Factor of a media-type is a measurement of the level of hypermedia support and sophistication of a media-type.
H Factor values can be used to compare and contrast media types in order to aid in selecting the proper media-type(s) for your implementation. H-Factor values are made up of two parts, each with their own set of factors: [MCA: Is this a complete list? Overkill?] By checking each hypermedia element in media-type for each of the identified factors, one can arrive at the composite 'H Factor' for the target media type. Example H Factor Charts When comparing media types, it can be helpful to document the existing H Factors in a simpel visual chart. Link Support Values: Support for embedded links (HTTP GET) Support for out-bound navigational links (HTTP GET) <a href=" title="view search page">Search</a> Support for templated queries (HTTP GET) <form method="get"><label>Search term:</label><input name="query" type="text" value="" /><input type="submit" /></form> Update History.
Building Hypermedia APIs with HTML5 and Node: Amazon.fr: Mike Amundsen: Livres anglais et étrangers. Mca blog [API for RDF? don't do it!] JSON-LD - JSON for Linking Data. Kimono : Turn websites into structured APIs from your browser in seconds. Opensource ne veut pas dire usage gratuit, l’exemple de la cartographie. Et oui l’opensource n’est pas gratuit, cela ne va pas plaire à bon nombre d’entreprises qui rêvent d’utiliser l’opensource pour dépenser moins!
Voici ma rapide analyse du marché de la cartographie en ligne pour les sites internet et les applications mobiles. Aujourd’hui beaucoup de sites web utilisent Google Maps pour afficher des plans ou des cartes. En effet, Google propose une API facile d’usage, gratuite avec certaines limites et performante. Pour les sites qui ont un peu plus de trafic et donc qui tombent dans les limites d’usage en fair use doivent passer sur l’offre payante de Google Maps qui elle n’est pas donnée (enfin elle l’est un peu plus maintenant).
Des alternatives basées sur l’opensource OpenStreetMaps existent et sont certes moins chères que l’offre de Google Maps. Dans ce cas ils vont devoir utiliser une bibliothèque d’affichage de carte (par exemple le très bon leaflet ou polymaps) et ensuite choisir un fournisseur de tuiles (tiles en anglais).