Articles taggés avec ‘Rest’

ArcDevelopper REST API

Lundi 10 mars 2008

Ca bouge chez ESRI, qui réinvente FeatureServer... Une interface REST en cours de développement mais déjà opérationnelle (l’exemple est fait avec OpenLayers, pas ArcIMS…) dans le cadre du projet ArcDevelopper illustre bien l’intérêt porté aux Architectures Orientée Ressources par les plus gros acteurs du marché SIG. Ca retourne même du GeoJSON (essayez ce lien : http://65.101.234.201/rest/rest.svc/TestService/Flyways/10?g=true) , preuve que ce format est en train de s’imposer tranquillement comme le standard pratique d’échange de données vectorielles sur le web, tandis que l’architecture REST procure souplesse et lisibilité. On aura l’occasion d’en reparler bientôt.

P.S. : même Microsoft s’intéresse à REST, le framework .NET 3.5 intègre une classe .NET d’URI templating, pour interpréter directement les URLs Restful selon des modèles prédéfinis…

Pour un 2008 RESTFul !

Lundi 17 décembre 2007

Il semblerait que quelques poids lourds (via zcologia) de l’industrie paleo-geographique et non des moindres s’orientent vers l’adoption d’architectures orientées ressources.

Histoire de finir l’année sur de bonnes résolutions pour celle à venir, quelques principes de base de la “Budgetecture” pour partir du bon pied donc.

Brevetage d’URL

Mercredi 24 octobre 2007

Ca semble un peu inouï dit comme ça, mais un brevet a été déposé par A9.com, une société du groupe Amazon.com, concernant un “Search engine system supporting inclusion of unformatted search string after domain name portion of URL”, soit en bon français : “Moteur de recherche acceptant l’inclusion d’une chaine de recherche non formatée après le nom de domaine dans l’URL”, donc quelque chose du genre : http://www.recherche.com/spaghetti bolognaise (les espaces sont acceptés). Voir ici pour les détails. Il y est précisé que le principe breveté concerne la soumission d’une chaîne de caractères à un moteur de recherche si cette chaîne ne correspond pas à une ressource existante.
Est-ce que cela signifie que toute structuration un rien RESTFul tombe dans le champ d’application de ce brevet pour peu que l’URL corresponde au modèle breveté ? Si http://www.communes.com/31555 pointe sur une ressource, ça semble bon, mais si http://www.communes.com/Toulouse passe au travers d’un mod_rewrite qui appelle http://www.communes.com/search.php?q=Toulouse pour renvoyer ensuite la ressource http://www.communes.com/31555, on est bien dans le champ d’application du brevet.

Je ne suis pas spécialiste des brevets, mais je frissonne déjà à l’idée de devoir vérifier si ma structuration d’URL, et donc l’architecture de mon application web, ne tombe pas sous une telle protection. Car si A9.com a pu le faire pour quelque chose d’aussi simple et basique, qui va se gêner ? Wikipedia pourrait deposer les URL en http://xxxx/wiki/chaine_de_recherche par exemple. Enorme bourde de l’USPTO ou nouvel eldorado des verrouilleurs de tout poil ?

Via slashdot

Heureuse initiative

Vendredi 27 juillet 2007

Chris Schmidt et Howard Butler viennent de mettre en ligne un petit site web qui référence les projections EPSG et des projections personnelles, chargées par les utilisateurs du site. Rien de bien excitant ? Et bien si, car ils mettent aussi à disposition des webservices de publication des définitions des projections, aux formats GML, Proj4, EsriWKT, OGC WKT, USGS et JSON. Grâce à une architecture RESTFull, les définitions (ou les ressources, pour utiliser la terminologie REST) sont accessibles par un simple appel d’URL :

http://spatialreference.org/ref/epsg/27572/Proj4 renvoie ainsi un flux texte correspondant au Lambert II structuré selon la norme Proj4.

L’intérêt ? Pouvoir à terme intégrer ces URL en lieu et place des définitions elles-mêmes dans l’utilisation de GDAL ou de MapServer par exemple. Donc un moyen simple d’accéder à des définitions maintenues à jour, sans avoir à mettre les mains dans les fichiers EPSG de la librairie proj, ainsi que de créer ou d’utiliser des projections non définies par l’EPSG.

Autre intérêt du site : bâti autour du framework Django, donc écrit en Python, avec une architecture REST, il montre ce que ces technologies peuvent apporter en termes de simplicité et de flexibilité dans la mise en oeuvre de webservices cartographiques.