API como SaaS

684 views
545 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
684
On SlideShare
0
From Embeds
0
Number of Embeds
76
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

API como SaaS

  1. 1. @ideup #theapihourAPI como SaaSinformación como valor añadido@ideup #theapihour
  2. 2. @ideup #theapihourideup.Experiencias digitales de máxima rentabilidadwww.ideup.com | ideupBlog | @ideup | Linkedin | Facebook | +34 91 636 63 24Arquitecto web en ideupE-mail: pablo.lopez@ideup.comTwitter: @plopesc
  3. 3. @ideup #theapihourSaaS es un modelo de distribución de software donde elsoporte lógico y los datos que maneja se alojan en servidoresde una compañía, a los que se accede con un navegador webdesde un cliente, a través de Internet.Una API (Interfaz de programación de aplicaciones) es elconjunto de funciones y procedimientos (o métodos, enla programación orientada a objetos) que ofrececierta biblioteca para ser utilizado por otro software como unacapa de abstracción.¿SaaS? ¿API? ¿API como SaaS?
  4. 4. @ideup #theapihour¿SaaS? ¿API? ¿API como SaaS?
  5. 5. @ideup #theapihourInteroperabilidad máquina-máquinaGeneralmente, clientes y servidores que, siguiendo elestándar SOAP, intercambian mensajes en XML.En los últimos años, se ha hecho muy popular un estiloarquitectónico conocido como REST.¿Servicio Web?
  6. 6. @ideup #theapihour¿Servicio Web?RPC (Llamadas a procedimientos remotos)SOA (Arquitectura Orientada a Servicios)REST (Representation State Transfer)
  7. 7. @ideup #theapihour¿Servicio Web?RPC (Llamadas a procedimientos remotos)SOA (Arquitectura Orientada a Servicios)REST (Representation State Transfer)lLigerolSencillolInteroperablelEscalable
  8. 8. @ideup #theapihour¿Por qué REST?
  9. 9. @ideup #theapihourAPI en la Actualidad
  10. 10. @ideup #theapihourAPI en la Actualidad
  11. 11. @ideup #theapihourAPI en la Actualidad
  12. 12. @ideup #theapihourAPI en la Actualidad
  13. 13. @ideup #theapihourAPI REST enEn deupelegimos el estilo de arquitectura que nos ofreceREST por diversas razones:• Nos sentimos muy cómodos con el protocolo HTTP• La experiencia digital que tenemos nos dice que es el estilomás adecuado para muchos de nuestros clientes• Tenemos experiencia consolidada con Drupal y Symfony y seadaptan muy bien a REST• La arquitectura se simplifica al máximo, por lo queobtenemos más rendimiento• Las peticiones también se simplifican, es decir, ganamosvelocidad de procesamiento• Los resultados son visualmente interpretables• Fácilmente escalable• Curva de aprendizaje prácticamente inexistente
  14. 14. @ideup #theapihourAPI RESTREST está orientado a recursos:• REST no es RPC, por lo tanto no publicamos verbos comoalquilar, sino publicamos nombres como película o socio.• Cada recurso posee un identificador único universal• La implementación de un recurso es privada y no accesibledesde el exterior• Cada recurso tiene una interfaz o conjunto de operacionesque admite• La interfaz es homogénea para todos los recursos• Las operaciones son stateless
  15. 15. @ideup #theapihourAPI RESTLos servicios REST son multimedia, es decir, podemos usarlas cabeceras Accept y Content-Type para negociar qué tipoMIME vamos a usar en la comunicaciónUna única URI para poder acceder al mismo recurso endiferentes formatoshttp://midominio.es/rest/pelicula/43abb4bb4
  16. 16. @ideup #theapihourAPI RESTA la hora de modelar APIs, REST nos da la facilidad de hacerlode diferentes modos, dependiendo del fin que tengamos.La forma más fácil de diseñar una API REST es siguiendo unestilo orientado a datos (u operaciones CRUD). Cada URIrepresenta una tabla o entidad y mediante los verbos HTTPdefinimos las operaciones de edición y lectura.HTTP CRUD DescripciónPOST CREATE Crear un nuevo recursoGET RETRIEVE Obtener la representación de unrecursoPUT UPDATE Actualizar un recursoDELETE DELETE Eliminar un recurso
  17. 17. @ideup #theapihourAPI RESTNo es necesario acoplar API al modelo de persistencia dedatos.En muchos casos diseñar el API con este tipo de orientaciónsería más que suficiente, pero en muchos otros no lo es.El API debe cumplir su principal objetivo: Ser útil para elusuarioEn este punto es cuando le podemos ver la utilidad alconcepto de hypermedia
  18. 18. @ideup #theapihourAPI REST - HYPERMEDIAUsuario no debe conocer el API completaCliente capaz de autodescubrir todas lasposibilidades de la aplicación de formaautónoma
  19. 19. @ideup #theapihourAPI REST: apunteslConcurrencialEtag y persistencialSeguridad
  20. 20. @ideup #theapihourAPI REST: apuntesDesde la implementación, para asegurarnos que estamoscreando un aplicativo escalable, tenemos que intentar evitarel máximo de operaciones posibles.Para ello, podemos usar o implementar un sistema de cachéen la aplicación de tal modo que sólo creemos el resultadocuando el almacenado en la caché haya cambiado.Podemos usar varios métodos entre los que destacamos losdos siguientes:• If-None-Match y Etag: Se realiza un GET condicional de talmodo que sólo devolveremos con la nueva información siésta ha cambiado. El código de respuesta 304 indica que elrecurso solicitado no ha cambiado.• If-Modified-Since y Last-Modified: En este caso, secomprueba la fecha de modificación del recurso y, si hapasado, se devuelve la información del servidor. Los relojesdel servidor y cliente deberían estar sincronizados.
  21. 21. @ideup #theapihourInfraestructuras de SistemasEn ideu los proyectos que realizamos (en su mayoría) estánimplementados bajos infraestructuras LAMP, con algunasmejoras en ciertos casos para lograr una mayor escalabilidad.
  22. 22. @ideup #theapihourCaso de éxito: Agregador de cupones
  23. 23. @ideup #theapihourNotas Finales• Busca siempre la simplicidad en la implementación. Es loque hará que el desarrollo del proyecto no se desborde.• Nuestra API no sólo debe ser simple y fácil de usar, sino queademás debe parecerlo: una buena documentación, sencillapero completa, para que el programador tercero puedausarla con éxito.• Escucha a tus nuevos clientes, los programadores: elfeedback es importantísimo para la madurez de la API.• Antes de acometer la fase de diseño e implementación,hacer un estudio de lo que realmente es útil y lo que va anecesitar nuestro cliente.• Usamos API REST para aprovechar la escalabilidad delprotocolo HTTP: Respeta su semántica.
  24. 24. @ideup #theapihourAPI como SaaSinformación como valor añadido@ideup #theapihour

×