Me pregunto si es posible descubrir mediante programación todos los puntos finales de una API en particular.
Entonces, por ejemplo, si OBTENGO esta URL con un navegador o curl: https://api.twitter.com/1.1/
Podría obtener algo como esto como una respuesta JSON:
"TwitterAPI":{ "version" : 1.1, "GET" : { "search/" : ["users", "trending"], "users/" : ["id", "handle"] } }Por supuesto Twitter podría optar por publicar o no publicar este formato. Entonces, como pregunta adicional, ¿hay alguna biblioteca para Java o JavaScript que mapee y publique automáticamente las rutas API que creó en sus controladores?
No hay forma de descubrir mediante programación los servicios REST, ya que no tienen un servicio de registro estándar.
Además de hacer una locura de búsqueda de fuerza bruta, no hay forma de encontrar las URL correctas (sin mencionar los parámetros correctos). Entonces, la única opción es documentar su API. Para eso, la mejor opción que he visto hasta ahora es:
Algunas API RESTful publican un recurso de lenguaje de descripción de aplicaciones web (WADL, pronunciado como el paseo que hacen los patos, para abreviar). JAX-RS, o al menos Jersy webapps, hará esto de forma predeterminada en la URL raíz de la aplicación /application.wadl. No parece que la API de Twitter sea una de ellas. Muchos puristas de REST argumentarían que la API debe ser autodescriptiva y autodetectable simplemente interactuando con ella y viendo qué otros puntos finales le proporcionará.
Debería poder descubrir todo lo que necesita saber sobre una API REST con solo conocer el punto de entrada inicial. Este es uno de los puntos fundamentales de REST; que debe ser impulsado por hipermedia y autodescriptivo. También es uno de los principios menos comprendidos. El descubrimiento de recursos se debe a los enlaces hipermedia en las respuestas del servidor.
Ya en 2008, Roy Fielding comenzó a molestarse con las personas que escribían API basadas en HTTP y las llamaban REST solo porque era lo nuevo. Aquí hay un par de puntos que hace;
Una API REST no debe definir jerarquías o nombres de recursos fijos (una combinación obvia de cliente y servidor). Los servidores deben tener la libertad de controlar su propio espacio de nombres. En su lugar, permita que los servidores instruyan a los clientes sobre cómo construir los URI apropiados, como se hace en los formularios HTML y las plantillas de URI, definiendo esas instrucciones dentro de los tipos de medios y las relaciones de enlace. [La falla aquí implica que los clientes están asumiendo una estructura de recursos debido a la información fuera de banda, como un estándar específico de dominio, que es el equivalente orientado a datos del acoplamiento funcional de RPC].
y
Se debe ingresar una API REST sin conocimiento previo más allá del URI inicial (marcador) y un conjunto de tipos de medios estandarizados que sean apropiados para la audiencia prevista (es decir, que se espera que los entienda cualquier cliente que pueda usar la API). A partir de ese momento, todas las transiciones de estado de la aplicación deben estar impulsadas por la selección del cliente de opciones proporcionadas por el servidor que están presentes en las representaciones recibidas o implícitas en la manipulación de esas representaciones por parte del usuario. Las transiciones pueden estar determinadas (o limitadas por) el conocimiento del cliente de los tipos de medios y los mecanismos de comunicación de recursos, los cuales pueden mejorarse sobre la marcha (por ejemplo, código bajo demanda). [La falla aquí implica que la información fuera de banda está impulsando la interacción en lugar del hipertexto].
Lo que esto significa en la práctica es que el punto de entrada (normalmente usando el URI raíz de "/") contiene enlaces a otras API REST. Esas API contendrán enlaces a otras API y así sucesivamente. No debería haber ninguna API que no tenga un enlace a ella. Eso significaría que no es detectable.
Las otras respuestas aquí son fundamentalmente incorrectas porque no reconocen el principio más básico de REST.