Estoy tratando de aclarar un concepto relacionado con la capacidad de descubrimiento REST, es decir, si la satisfacción de la restricción HATEOAS para un servicio RESTful significa que ahora los URI pueden cambiar, porque son detectables y no están documentados.¿la capacidad de descubrimiento REST y HATEOAS implican que puede cambiar los URI?
Eso parece no seguir el concepto de Cool URIs - el hecho de que los URI no cambian, nunca. También es algo inconsecuente con el modelo de la web en sí (que REST debería ajustarse perfectamente): el hecho de que las URL son bookmarkable y nunca cambian, y el hecho de que una vez que aprendes una, puedes ir directamente a ella y lo haces no tiene que pasar por la raíz y descubrirlo cada vez.
Se agradece cualquier comentario sobre esto.
Gracias por la rápida respuesta. He leído el artículo, pero todavía no tengo claro algunas cosas: primero, ¿no es para eso para lo que está la API? y segundo, ¿debería haber ALGUNA documentación? Tengo entendido que en una implementación RESTful pura, la documentación sería casi nula. ¿Sería mejor usar solo URL geniales y hacer una versión diferente de la API para un cambio tan radical? – Eugen
La creación de versiones de una API puramente para mantener la compatibilidad de estructura URI conduce a los mismos problemas que tener un WSDL para cada versión de su servicio web: no está evolucionando su servicio, está agregando nuevas versiones (mayormente duplicadas) cada vez que tendrá que probar, mantener, documentar, etc. Hacer eso y despedirse de un gran beneficio de REST: la evolución dinámica de sus "contratos" y un maravilloso desacoplamiento entre el cliente y el servidor. –
Y en cuanto a no tener documentación, seguro: cuando todo el mundo del software haya desarrollado experiencia con REST, tendrá mucho sentido. Siempre habrá novatos que quieran usar tu API, y no darles nada con lo que trabajar no tenga sentido para mí. Claro, un experto en REST probablemente podría sentarse y resolverlo todo, pero ese no es el mundo en el que vivimos.Documente sus tipos de medios y la semántica de cada recurso y proporcione un código de muestra que muestre cómo se deben construir los clientes bien construidos, y todo irá bien. –