2009-09-24 17 views
9

Esta es una pregunta de varias partes. Acabo de ver una presentación muy interesante sobre YQL por el desarrollador principal (un graduado de mi programa de MS). Si bien fue muy convincente, y estoy deseando probarlo, me pregunto si alguien sabe de marcos alternativos para consultar múltiples API de servicios web para que aparezcan sin problemas, el aparente propósito de YQL?Alternativas a YQL

La estrategia de Yahoo ha sido crear definiciones de esquemas XML que unen los parámetros de un determinado servicio web en sus parámetros de consulta YQL Open Table, lo que creo que es muy inteligente. ¿Hay alguna herramienta que intente (quizás soy ingenuo aquí) automatizar el descubrimiento de parámetros en, por ejemplo, una API REST? Soy consciente de que con las API de SOAP, porque hay un WSDL publicado, facilita la automatización, pero ¿todavía no hay manera de hacerlo con REST? ¿Alguien está intentando?

+0

Soy muy escéptico de que exista una herramienta de descubrimiento automático para API REST, ya que la misma entidad puede tener muchas representaciones diferentes. Y puede definir ad-hoc qué parámetros acepta. WADL intenta mejorar las cosas, pero creo que está muerto en el agua, ya que va en contra de la mentalidad minimalista de los desarrolladores de REST. Buena pregunta.+1 –

Respuesta

5

Sí, las personas están tratando de producir los idiomas de descripción para REST. El esfuerzo más popular es WADL. Hay muchas preguntas sobre WADL aquí en SO. ¿Es una buena idea? En mi opinión, no.

REST no necesita un modelo de descubrimiento más allá de lo que ya tiene con hipermedia, porque está tratando de resolver un problema en una capa arquitectónica diferente que los servicios web. Los servicios web entregan datos a la lógica de negocios/modelo de dominio de una aplicación. REST consiste en entregar contenido y comportamiento a una capa de presentación.

¿Qué tal una analogía? Piense en las diferencias entre un objeto y una estructura en C++. Una estructura es solo datos simples que algún proceso del cliente va a manipular. Eso es lo que hace un servicio web, devuelve una gran cantidad de datos, una estructura. Claro que tal vez hizo un montón de procesamiento del lado del servidor para producir el resultado, pero el resultado final es un conjunto de datos. Una interfaz REST entrega un objeto. es decir, contiene tanto los datos como los métodos que se pueden usar para manipular ese objeto. Por definición, si comprende la interfaz uniforme y entiende el tipo de medio devuelto, ya sabe lo que puede hacer con la respuesta. Los mecanismos de descubrimiento son redundantes.

Si le resulta difícil de creer, piense en la web. ¿Cómo descubre un navegador web las páginas web? La web no tiene un mecanismo de descubrimiento formalizado y, sin embargo, existe un mundo de información que podemos descubrir con un navegador web.

+0

No estoy de acuerdo con esta respuesta, no creo que REST se limite solo a entregar contenido (y comportamiento) a una "capa de presentación". Y considero una mala práctica de comportamiento vinculante para REST. – ElLocoCocoLoco

+0

@ElLocoCocoLoco Si me ayudaras a comprender cuáles de las restricciones de REST se están violando por "comportamiento vinculante para REST" y los efectos negativos del sistema de esas violaciones, entonces quizás pueda entender por qué consideras que es una "mala práctica". –

+0

¿Entiende francés? https://fr.wikipedia.org/wiki/Representational_State_Transfer Al entregar "comportamiento" supongo que está hablando de la sexta (restricción opcional) Code-On-Demand de los servicios REST. Si ese es el caso, entonces eso generalmente se considera una mala práctica porque "un estado se vuelve dependiente del cliente y no del servidor que contradice la Regla 2". Si está hablando del punto 4.3 "las respuestas explican su naturaleza", incluso en este caso necesitamos algunos servicios para explicar la naturaleza de los resultados antes de ejecutar la solicitud (Adaptative/Auto discovery Systems) – ElLocoCocoLoco

1

Hay este pequeño sitio web http://zachgrav.es/yql/tablesaw/ que de hecho autodescubre los parámetros en una API REST y la convierte en una tabla compatible con YQL.

1

Hay dos formas de buscar información. O usa un lenguaje 100% inequívoco o usa un lenguaje natural. Cualquier cosa intermedia, como YQL, está condenada a fallar porque no ofrece ninguno y funciona bien solo con los ejemplos promocionados por sus autores.

He escrito sobre esto en http://zscraper.wordpress.com/2012/05/30/enough-with-crawling-2. Mi postura personal es que siempre obtendrás los resultados más precisos si primero haces tu tarea, es decir, estudiar el dominio de destino y averiguar cómo consultarlo sin ambigüedades.

Para responder a su pregunta y darle una alternativa, intente Bobik. Este es un servicio de rastreo respaldado por la nube que usted controla a través de la API REST. Componga sus "consultas" en la sintaxis tradicional (Bobik admite Javascript, JQuery, XPATH y CSS) y llame a Bobik para que las ejecute desde cualquier entorno del lado del cliente (páginas web, aplicaciones móviles o su servidor).

Espero que esto ayude.

+3

El sitio web, http://usebobik.com, ya no existe. También creo que el servicio ya no está disponible. – Ragaar