Principios de diseño de APIs REST – Enrique Amodeo ¿Por qué razón debería preocuparme si mi sistema tiene o bien no una API web? Existen por lo menos 2 razones que son importantes: costos y negocios. La mayoría de los costos en la industria del software proceden del mantenimiento, conque resulta conveniente preguntarnos: ¿qué es más mantenible, un sistema monolítico con millones de líneas de código? ¿O bien un sistema modular, donde cada subsistema colabore con el resto a través de una API bien definida? Evidentemente lo segundo. Siguiendo este hilo de pensamiento, dichos subsistemas deberían tener entre si el menor acoplamiento posible; cada uno de ellos debería poder ser parado, arrancado y mantenido separadamente, y también incorporados en la tecnología más conveniente a su funcionalidad. Desde esta observación brotó el término de servicios web y aparecieron los Enterprise Service Autobus y demás productos de integración empresarial. Y desde la perspectiva de los negocios, ¿qué es más eficaz, una compañía que procura solventar todos y cada uno de los inconvenientes derivados de su negocio? ¿O bien una compañía que se dedica solo a lo esencial de su negocio, a progresar de manera continua su producto, y contrata los detalles no esenciales a sus distribuidores? El creador no es un empresario de éxito (por el momento), mas semeja que la tendencia va en en esta última dirección. Mas en la era de la información, el que 2 empresas deseen cooperar de forma eficiente implica que sus sistemas de información deben cooperar de igual modo, con lo que las dos empresas deben contar con APIs que dejen dicha cooperación. En este punto no es suficiente una API que esté desarrollada especificamente a fin de que las compañías A y B cooperen. No, es considerablemente más eficiente que tu empresa tenga una API que dejara a múltiples partners cooperar contigo. No es deseable tener que efectuar un nuevo desarrollo para cada uno de ellos de ellos. Si unimos esta necesidad de cooperación entre negocios, con la necesidad de integración entre subsistemas, cobra sentido el que los dos inconvenientes se resuelvan con exactamente la misma solución: una API web. En un comienzo se utilizó tecnología SOAP para incorporar estas APIs web, mas los resultados no fueron completamente satisfactorios. Incluso de este modo, por un tiempo esta tecnología subsistió a base de una enorme campaña de comercialización y de que por lo menos funcionaba (si bien fuera de una manera un tanto precaria). No obstante este no es el fin de la historia. Con el advenimiento de la página web dos.0, las aplicaciones móviles, webs con capacidades AJAX, y la explosión de start-ups en el planeta web, las APIs web han dejado de ser una pura solución de conveniencia para solucionar los inconvenientes de integración y de Business to Busisness, y han pasado a transformarse en una necesidad. En verdad en la actualidad la API web puede ser en si misma el producto que deseamos comercializar. Hoy día es frecuente que se pague por el empleo de una API en caso de que el consumo sea intensísimo. Es normal tener miles y miles de millones de llamadas en las APIs más populares (Google, ebay, twitter, fb, netflix, amazon, accuweather, klout,salesforce, linkedin). Conque las APIs web pueden ser una fuente de ingresos bastante respetable. En vista de estas circunstancias las APIs web han de estar diseñadas de tal modo que sean fáciles de consumir, no solo desde otros servidores, sino más bien asimismo desde otros clientes del servicio con menores capacidades de cálculo, como dispositivos móviles yweb. Todo esto hace que el enfoque SOAP a la construcción de APIs web sea cada vez menos conveniente, y que el enfoque REST haya triunfado. Cuanto más fácil de utilizar sea nuestra API, más usuarios va a tener y nos va a ofrecer mayores ocasiones de negocio. En el instante de redactar este libro hay unas 7 mil APIs públicas, esto es una señal propia de que todo esto no es una teoría sino más bien una realidad, de que entramos en la era de la página web programable. : Sobre la cubierta Novedades en esta versión Agradecimientos Érase una vez… 1. La página web programable: APIs y más APIs dos. ¿Qué es REST? dos.1. Definición dos.2. ¿Por qué razón emplear REST? tres. REST en la práctica: http tres.1. Introducción tres.2. URIs tres.3. Los verbos http tres.4. Los modelos MIME tres.5. Códigos de estado tres.6. QoS en http tres.7. http y REST cuatro. APIs orientadas a datos: CRUD cuatro.1. Introducción cuatro.2. Leyendo cuatro.3. Actualizando cuatro.4 Borrando cuatro.5. Creando cuatro.6. Probablemente CRUD no sea lo mejor para tu API… cinco. Buenas prácticas y patrones de diseño básicos cinco.1. Respeta la semántica de http cinco.2. Servicios multimedia cinco.3. Concurrencia optimista cinco.4. Cache cinco.5. Multidioma cinco.6. Prácticas básicas de seguridad en REST cinco.7. Actualizaciones parciales cinco.8. Versionado de API cinco.9. ¿Necesito una sesión http? cinco.10. Solicitudes asíncronas o bien de larga duración cinco.11. URIs tirables y recursos “virtuales” cinco.12. Procesos de negocio cinco.13. Procesos versus. Solicitudes asíncronas seis. Hypermedia APIs seis.1. Introducción seis.2. El término de hypermedia seis.3. Consultas autodescubribles y URI Templates seis.4. Controles hypermedia seis.5. Web Linking seis.6. Patrón Envelope seis.7. Servicios web autodescriptivos seis.8. ¿Qué modela nuestra API? ¿Aplicaciones o bien procesos? seis.9. ¿Un tipo mime por API? siete. Hypertext Application Language (HAL) siete.1. Introducción siete.2. Enlaces siete.3. Recursos engastados siete.4. Curie siete.5. Un caso siete.6. HAL y XML siete.7. Conclusión ocho. SIREN ocho.1. Introducción ocho.2. Datos ocho.3. Géneros de datos ocho.4. Enlaces ocho.5. Recursos engastados ocho.6. Formularios ocho.7. SIREN y XML ocho.8. SIREN vs. HAL nueve. Collection+JSON nueve.1. Introducción nueve.2. Datos nueve.3. Enlaces nueve.4. Consultas nueve.5. Formularios nueve.6. Conclusiones diez. (X)HTML diez.1. Introducción diez.2. HTML como formato de datos diez.3. Links y formularios diez.4. Conclusiones once. Atom y AtomPub once.1. Introducción once.2. Servicios y autodescubrimiento once.3. Feeds y entries once.4. Media Resources versus. Media Entries once.5. Manipulando elementos de una compilación once.6. Conclusiones doce. Referencias y bibliografía