• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
API como SaaS
 

API como SaaS

on

  • 545 views

 

Statistics

Views

Total Views
545
Views on SlideShare
497
Embed Views
48

Actions

Likes
1
Downloads
2
Comments
0

4 Embeds 48

http://www.ideup.com 34
https://twitter.com 11
https://www.linkedin.com 2
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    API como SaaS API como SaaS Presentation Transcript

    • @ideup #theapihourAPI como SaaSinformación como valor añadido@ideup #theapihour
    • @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
    • @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?
    • @ideup #theapihour¿SaaS? ¿API? ¿API como SaaS?
    • @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?
    • @ideup #theapihour¿Servicio Web?RPC (Llamadas a procedimientos remotos)SOA (Arquitectura Orientada a Servicios)REST (Representation State Transfer)
    • @ideup #theapihour¿Servicio Web?RPC (Llamadas a procedimientos remotos)SOA (Arquitectura Orientada a Servicios)REST (Representation State Transfer)lLigerolSencillolInteroperablelEscalable
    • @ideup #theapihour¿Por qué REST?
    • @ideup #theapihourAPI en la Actualidad
    • @ideup #theapihourAPI en la Actualidad
    • @ideup #theapihourAPI en la Actualidad
    • @ideup #theapihourAPI en la Actualidad
    • @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
    • @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
    • @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
    • @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
    • @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
    • @ideup #theapihourAPI REST - HYPERMEDIAUsuario no debe conocer el API completaCliente capaz de autodescubrir todas lasposibilidades de la aplicación de formaautónoma
    • @ideup #theapihourAPI REST: apunteslConcurrencialEtag y persistencialSeguridad
    • @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.
    • @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.
    • @ideup #theapihourCaso de éxito: Agregador de cupones
    • @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.
    • @ideup #theapihourAPI como SaaSinformación como valor añadido@ideup #theapihour