Principios de diseño de APIs REST – Enrique Amodeo

Principios de diseño de APIs REST (desmitificando REST) Enrique Amodeo

¿Por qué debería preocuparme si mi sistema tiene o no una API web? Existen al menos dos razones que son importantes: costes y negocios.

La mayor parte de los costes en la industria del software provienen del mantenimiento, así que conviene preguntarnos: ¿qué es más mantenible, un sistema monolítico con millones de líneas de código? ¿O un sistema modular, donde cada subsistema colabore con los demás mediante una API bien definida? Obviamente lo segundo. Siguiendo este hilo de pensamiento, dichos subsistemas deberían tener entre si el menor acoplamiento posible; cada uno debería poder ser parado, arrancado y mantenido por separado, e implementados en la tecnología más adecuada a su funcionalidad. A partir de esta observación surgió el concepto de servicios web y aparecieron los Enterprise Service Bus y demás productos de integración empresarial.

Y desde el punto de vista de los negocios, ¿qué es más eficiente, una empresa que intenta solucionar todos los problemas derivados de su negocio? ¿O una empresa que se dedica sólo a lo esencial de su negocio, a mejorar continuamente su producto, y contrata los detalles no esenciales a sus proveedores? El autor no es un empresario de éxito (de momento), pero parece que la tendencia va en en esta última dirección.

Pero en la era de la información, el que dos empresas quieran colaborar de forma eficaz implica que sus sistemas de información deben colaborar de igual modo, por lo que ambas empresas deben contar con APIs que permitan dicha colaboración.

En este punto no es suficiente una API que esté desarrollada especificamente para que las empresas A y B colaboren. No, es mucho más eficaz que tu empresa tenga una API que permitiera a múltiples partners colaborar contigo. No es deseable tener que realizar un nuevo desarrollo para cada uno de ellos. Si unimos esta necesidad de colaboración entre negocios, con la necesidad de integración entre subsistemas, cobra sentido el que ambos problemas se resuelvan con la misma solución: una API web. En un principio se usó tecnología SOAP para implementar estas APIs web, pero los resultados no fueron del todo satisfactorios. Aun así, por un tiempo esta tecnología sobrevivió a base de una gran campaña de comercialización y de que al menos funcionaba (aunque fuera de una forma un tanto precaria).

Sin embargo este no es el fin de la historia. Con el advenimiento de la web 2.0, las aplicaciones móviles, webs con capacidades AJAX, y la explosión de startups en el mundo web, las APIs web han dejado de ser una mera solución de conveniencia para resolver los problemas de integración y de Business to Busisness, y han pasado a convertirse en una necesidad. De hecho hoy en día la API web puede ser en si misma el producto que queremos comercializar. Actualmente es común que se pague por el uso de una API en el caso de que el consumo sea muy intenso. Es normal tener miles de millones de llamadas en las APIs más populares (Google, ebay, twitter, facebook, netflix, amazon, accuweather, klout,salesforce, linkedin). Así que las APIs web pueden ser una fuente de ingresos bastante respetable.

En vista de estas circunstancias las APIs web deben estar diseñadas de tal manera que sean sencillas de consumir, no sólo desde otros servidores, sino también desde otros clientes con menores capacidades de cálculo, tales como dispositivos móviles y páginas web. Todo esto está haciendo que el enfoque SOAP a la construcción de APIs web sea cada vez menos adecuado, y que el enfoque REST haya triunfado. Cuanto más sencilla de usar sea nuestra API, más usuarios tendrá y nos ofrecerá mayores oportunidades de negocio.

En el momento de escribir este libro existen unas siete mil APIs públicas, esto es una señal distintiva de que todo esto no es una teoría sino una realidad, de que estamos entrando en la era de la web programable.

Contenido:

Sobre la cubierta
Novedades en esta versión
Agradecimientos
Érase una vez…
1. La web programable: APIs y más APIs
2. ¿Qué es REST?
2.1. Definición
2.2. ¿Por qué usar REST?
3. REST en la práctica: HTTP
3.1. Introducción
3.2. URIs
3.3. Los verbos HTTP
3.4. Los tipos MIME
3.5. Códigos de estado
3.6. QoS en HTTP
3.7. HTTP y REST
4. APIs orientadas a datos: CRUD
4.1. Introducción
4.2. Leyendo
4.3. Actualizando
4.4 Borrando
4.5. Creando
4.6. Seguramente CRUD no sea lo mejor para tu API…
5. Buenas prácticas y patrones de diseño básicos
5.1. Respeta la semántica de HTTP
5.2. Servicios multimedia
5.3. Concurrencia optimista
5.4. Cache
5.5. Multiidioma
5.6. Prácticas básicas de seguridad en REST
5.7. Actualizaciones parciales
5.8. Versionado de API
5.9. ¿Necesito una sesión HTTP?
5.10. Peticiones asíncronas o de larga duración
5.11. URIs desechables y recursos “virtuales”
5.12. Procesos de negocio
5.13. Procesos VS. Peticiones asíncronas
6. Hypermedia APIs
6.1. Introducción
6.2. El concepto de hypermedia
6.3. Consultas autodescubribles y URI Templates
6.4. Controles hypermedia
6.5. Web Linking
6.6. Patrón Envelope
6.7. Servicios web autodescriptivos
6.8. ¿Qué modela nuestra API? ¿Aplicaciones o procesos?
6.9. ¿Un tipo mime por API?
7. Hypertext Application Language (HAL)
7.1. Introducción
7.2. Links
7.3. Recursos incrustados
7.4. Curie
7.5. Un ejemplo
7.6. HAL y XML
7.7. Conclusión
8. SIREN
8.1. Introducción
8.2. Datos
8.3. Tipos de datos
8.4. Links
8.5. Recursos incrustados
8.6. Formularios
8.7. SIREN y XML
8.8. SIREN vs. HAL
9. Collection+JSON
9.1. Introducción
9.2. Datos
9.3. Links
9.4. Consultas
9.5. Formularios
9.6. Conclusiones
10. (X)HTML
10.1. Introducción
10.2. HTML como formato de datos
10.3. Enlaces y formularios
10.4. Conclusiones
11. Atom y AtomPub
11.1. Introducción
11.2. Servicios y autodescubrimiento
11.3. Feeds y entries
11.4. Media Resources VS. Media Entries
11.5. Manipulando elementos de una colección
11.6. Conclusiones
12. Referencias y bibliografía

Formato:  pdf Comprimido:  Sí Peso:  6.76 MB Lenguaje:  Español

Sin comentarios.

Deja tu Comentario