Rest Api

Un protocolo de comunicación para el tráfico entre webs

• A REST API is an application programming interface that conforms to
specific architectural constraints, like stateless communication and
cacheable data.
• It is not a protocol or standard. While REST APIs can be accessed
through a number of communication protocols, most commonly, they
are called over HTTPS, so the guidelines below apply to REST API
endpoints that will be called over the internet.
Accept and respond with JSON
• REST APIs should accept JSON for request payload and also send
responses to JSON.
• Almost every networked technology can use it. Included server-side
with libraries
• XML isn’t widely supported By Frameworks
• FormData(XML) its use to send Files.
¿Qué es?
• Una API es una abstracción de funciones y procedimientos
• Rest es una lógica de restricciones y recomendaciones bajo la cual se
puede construir una API (Como un estilo de arquitectura
• Y la resfullAPI es una API aplicada con la lógica de Rest.
• Utilizan estrictamente una arquitectura cliente servidor, utilizando http
como protocolo de comunicación.
¿Cómo sabe el servidor qué ejecutar?
• Aquí entra en juego las especificaciones de Rest
• Cada procedimiento de una Api esta compuesto por
• Un verbo HTTP ( ej POST)
• Una dirección URI única
• La información necesaria que requiere el servidor para satisfacer el requerimiento.

• Un verbo HTTP son identifciados que determinan el objetivo de un requerimiento del cliente,
a saber:
• GET: Se utiliza para devolver información al cliente.
• POST: El cliente crea recursos en el servidor
• PUT: El cliente edita recursos ya existentes.
• PATCH: El cliente edita recursos ya existentes.
• DELETE: El cliente elimina recursos del servidor.
Ventajas de REST
• La implementación de estos procedimientos de servidor no le interesa
al cliente
• Ni al servidor le importan las implementaciones dentro del cliente para
realizar los requerimientos
• Dos cajas negras que se comunican entre si
• Esto es así porque en la lógica REST el servidor debe recibir toda la
información necesaria para ejecutar el requerimiento.
Formas de envio de datos
• El formato de envio de información puede ser
• JSON (más utilizado)
• XML
• Formato Binario
• Texto plano
• Se debe tener toda la información necesaria para ejecutar el procedimiento
• Por ello REST es stateless, porque no necesita guardar información u estado de peticiones
anteriores para satisfacer nuevas.
• Cada petición es nueva.
• Representation State Transfer
¿Caché?
• REST tiene caché que nos permite guardar peticiones hechas con
anterioridad, que nos permite responder peticiones de manera más
rápida
El enfoque API first
• La API es tratada como “ciudadano de primera clase”,
• That everything about a project revolves around the idea that the end
product will be consumed by mobile devices, and that APIs will be
consumed by client applications.
• Se desarrolla inicialmente el modelo de API que se trabajará para
luego hacer los clients.
Event Driven
• El servidor se configura para enviar nuevos cambios al cliente.
Notificando eventos nuevos
• A diferencia del Restful Api aquí que pide al servidor. Aquí el servidor
entrega a quién se subscribió
• Event –enable son asincrónicas, push or streaming. Pushean en vez de
Pooling.
• Se requieren dos capacidades:
• Un mecanismo donde el cliente se subscriba a un evento de su interés
• Entregar información de un evento de forma asincrónica.
Tecnologías detrás del Event-Driven
• Webhooks
• Se registra una URL dónde es enviada la información cuando un evento
cambie, es decir, donde recibe el callback.
• No puede ser utilizado en Single Page Applications(SPA) o móviles,porque no
tienen HTTP endpoint.
• Sí funciona para server to server
• WebSockets
• Permite comunicación
• Server-Sent Events
•:
Tecnologías del EventSourcing
• EventSourcing nos permite crear trackeos de los cambios en los
registros, generando un log de cambios al cual podemos remitirnos
para restituir un archivo
• Más información:
https://martinfowler.com/eaaDev/EventSourcing.html
Restfull
vs
Event_Driven
Algunas observaciones
• Use Nouns Instead of Verbs in Endpoints
• No se debe ver así: https://mysite.com/getPosts or https://mysite.com/createPost
• Así sí: https://mysite.com/posts
• El http verb debe ser manejado el manejador pero no estar dentro del endpoint
• Name Collections with Plural Nouns
• So, instead of https://mysite.com/post/123, it should be https://mysite.com/posts/123.
• Use Status Codes in Error Handling
• Use Nesting on Endpoints to Show Relationships
• https://mysite.com/posts/author would make a valid nesting in this case
• https://mysite.com/posts/postId/comments
• Filtering, Sorting, and Pagination to Retrieve the Data Requested
• An example of a filtered endpoint is the one below:, https://mysite.com/posts?tags=javascript ; This endpoint will fetch any post that has a tag of JavaScript.
• Be Clear with Versioning
• REST APIs should have different versions, so you don’t force clients (users) to migrate to new versions.
• Many RESTful APIs from tech giants and individuals usually comes like this: https://mysite.com/v1/ for version 1 ; https://mysite.com/v2 for version 2
Pequeña guía de ayuda step by step
• https://apiary.io/how-to-build-api#style-guide

• Pequeños
Diseño 1
• Identify the resources – Object Model
• Debemos identificar los recursos que iremos a exponer, que se transformará en nuestra estructura
URI. Use Nouns instead of Verbsin Endpoints
• Pantalones, remeras, zapatillas
• Celulares,cargadores,fundas
• Carpinteria,herreria
• Create Model Uris - Debemos identificar los recursos que iremos a exponer, que se transformará
en nuestra estructura URI
• Localhost/prendas/pantalones/{:id]
• Localhost/tecnologia/celulares/[:id]/configuracion
• Localhost/servicios/:id
• Determine Resource Representations – XML or Json
Diseño 2
• Collection Resource of Devices
• Cuando se trata de colecciones es importante no devolver todo el objeto en el
caso de tener muchos valores