Alternatives à YQL

Question

Ceci est une question en plusieurs parties. Je viens de regarder une présentation très intéressante sur YQL par le développeur principal (un diplômé de mon programme MS). Alors que c'était très convaincant, et je suis impatient de l'essayer, je me demande si quelqu'un connaît des cadres alternatifs pour interroger plusieurs API de service Web pour les rendre transparents, l'objectif apparent de YQL?

La stratégie de Yahoo a été de créer des définitions de schéma XML qui lient les paramètres d'un service Web donné dans leurs paramètres de requête YQL Open Table, ce qui, à mon avis, est très intelligent. Y at-il un outil qui tente (peut-être je suis naïf ici) d'automatiser la découverte des paramètres dans une API REST, par exemple? Je suis conscient qu'avec les API SOAP, parce qu'il existe un WSDL publié, cela facilite l'automatisation, mais n'y a-t-il pas encore moyen de le faire avec REST? Est-ce que quelqu'un essaie?

Answer 1

Oui, les gens essaient de produire des langages de description pour REST. L'effort le plus populaire est WADL. Il y a beaucoup de questions sur WADL ici sur SO. Est-ce que c'est une bonne idée? À mon avis non. REST n'a pas besoin d'un modèle de découverte au-delà de ce qu'il possède déjà avec hypermédia, car il essaie de résoudre un problème sur une couche architecturale différente de celle des services Web. Les services Web fournissent des données au modèle de logique métier/domaine d'une application. REST consiste à fournir du contenu et du comportement à une couche de présentation.

Que diriez-vous d'une analogie? Pensez à la différence entre un objet et une structure en C++. Une structure est juste des données simples que certains processus client vont manipuler. C'est ce que fait un service web, il renvoie un morceau de données, une structure. Bien sûr, il a peut-être fait beaucoup de traitement côté serveur pour produire le résultat, mais le résultat final est une masse de données. Une interface REST délivre un objet. c'est-à-dire qu'il contient à la fois des données et les méthodes qui peuvent être utilisées pour manipuler cet objet. Par définition, si vous comprenez l'interface uniforme et que vous comprenez le type de média renvoyé, vous savez déjà ce que vous pouvez faire avec la réponse. Les mécanismes de découverte sont redondants.

Si vous trouvez cela difficile à croire, la réflexion sur le web. Comment un navigateur Web découvre-t-il les pages Web? Le Web n'a pas de mécanisme de découverte formalisé, et pourtant il y a un monde d'informations que nous pouvons découvrir avec un navigateur web.

Answer 2

Il ya ce petit site Web http://zachgrav.es/yql/tablesaw/ qui en effet auto-découvre les paramètres dans une API REST et le transforme en une table compatible YQL.

Answer 3

Il y a deux façons de trouver l'information. Soit vous utilisez un langage 100% sans ambiguïté, soit vous utilisez un langage naturel. Tout ce qui se trouve entre les deux, comme YQL, est voué à l'échec parce qu'il ne livre pas et ne fonctionne bien qu'avec les exemples que ses auteurs vantent.

J'ai blogué à ce sujet au http://zscraper.wordpress.com/2012/05/30/enough-with-crawling-2. Ma position personnelle est que vous obtiendrez toujours les résultats les plus précis si vous faites d'abord vos devoirs, c'est-à-dire étudiez le domaine cible et trouvez comment l'interroger sans ambiguïté.

Pour répondre à votre question et vous donner une alternative - essayez Bobik. Il s'agit d'un service de scrapage protégé par le cloud que vous contrôlez via l'API REST. Composez vos "requêtes" en syntaxe traditionnelle (Bobik supporte Javascript, JQuery, XPATH et CSS) et appelez Bobik pour les exécuter depuis n'importe quel environnement côté client (pages web, applications mobiles, ou votre serveur).

Espérons que cela aide.