2009-11-24 24 views
23

Cuando quiero encontrar un servicio web "grande" (basado en WS - */WSDL) de la funcionalidad requerida, simplemente puedo buscar en google ".... filetype: wsdl" porque Google indexa también las definiciones WSDL. O simplemente puedo usar algunos registros que ya han rastreado la Web para las definiciones de WSDL para mí, p. SeekDa.com o ServiceFinder.¿Cómo descubro los servicios web RESTful?

Cuando quiero encontrar un servicio web RESTful (API web RESTful) puedo contar solo con la comunidad, porque no es posible distinguir entre URI de servicio web RESTful y otros recursos web (por ejemplo, URL de sitios web) y por lo tanto cualquier rastreador enfocado no puede decir con seguridad al 100%: esto es URI del servicio web RESTful. Entonces, vengo, por ejemplo a ProgrammableWeb.com y espero que alguien ya haya utilizado/encontrado el servicio que estoy buscando y lo haya registrado allí.

Recientemente, estaba buscando el servicio web para la expansión de abreviatura. No pude encontrarlo en portales como ProgrammableWeb, porque nadie lo ha puesto allí. Finalmente me vi obligado a navegar por varios sitios de diccionarios de abreviaturas, cavar y perforar allí y finalmente encontré la API de servicios web de Abbreviations.com en forma REST. ¡Eso me llevó mucho tiempo!

¿Hay alguna otra forma de descubrir los servicios web RESTful en la Web?

Respuesta

9

El RESTO ideal es que los servicios son tan consumibles como las páginas web, no necesitan registros. [Tengo que admitir que no entiendo del todo las implicaciones de este mundo REST, no WSDL, ningún registro se siente como andar en bicicleta sin estabilizadores.]

En la web anterior, antes de Google, ¿cómo lo hicimos? encontrar páginas? De boca en boca y algunos puntos de partida clave. Los servicios REST hasta donde puedo ver están prácticamente en la etapa previa a Google.

No estoy de acuerdo con que "no es posible distinguir entre URI del servicio web RESTful y otros recursos web" - si seguimos el enlace obtenemos ciertos tipos de contenido application/xml y application/json sería bastante indicadores fuertes, ¿no?

+0

Gracias. No he considerado los tipos MIME de la respuesta del servicio :-) – dzieciou

+0

Solo un comentario: nunca está seguro de si la aplicación/xml se generó en la llamada (como respuesta al servicio) o es un documento XML estático. Entonces este es solo uno de los indicadores posibles. ¿Cualquier otra sugerencia? – dzieciou

+1

No necesita saber eso. Provocado satisface el URI no puede exigir cómo se debe servir. Algunas respuestas podrían precalcularse y almacenarse en caché. – djna

7

Hay un archivo similar al WSDL para los servicios web REST: se llama WADL.

+2

Gracias. Esa es una buena idea suponiendo que los servicios web RESTful se describen con WADL. Pero actualmente solo es idea, no son prácticas comunes. Volviendo al mundo real: ¿cómo puedo encontrar un servicio web RESTful interesante AHORA? – dzieciou

+0

a menos que los conozca, no puede. Eso es lo que WADL intenta resolver. –

+1

OK. Por cierto, ¿conoce alguna investigación sobre la extracción de definiciones WADL del documento de la API, páginas web asociadas? ¿Alguna prueba?Eso sería una buena forma de generar WADL-s de forma semiautomática y proporcionar una transición suave (evolución en lugar de revolución) de la falta actual de interfaces para servicios web RESTful. – dzieciou

8

Existe una convención (recomendada en REST API Design Handbook por ejemplo) que expone un punto final/api en la raíz de su servicio. Esto devuelve una respuesta XML o JSON que contiene los recursos "secundarios" que su servicio admite, p./api/productos

+1

¿Tiene un enlace a esa guía? Mejorará en gran medida tu respuesta ... –

1

SoapUI ahora pueden descubrir los servicios REST. Funciona como un proxy, anotando todas las solicitudes/respuestas que pasan. Tener solicitudes y respuestas SoapUI recrea descripciones/definiciones de los servicios. Ahora las definiciones se pueden almacenar en formatos WADL y WSDL (como WSDL y XML-Schema en el mundo XML). También se puede almacenar en formato Swagger. Prefiero Swagger. Swagger se puede almacenar en SwaggerHub directamente desde SoapUI, que es como GitHub para el código fuente. SwaggerHub es uno de los muchos sistemas de administración de API.

Cuestiones relacionadas