Si estas empezando en el desarrollo web FrontEnd o backend, probablemente ya has escuchado el Termino API Rest, y si aun no lo entiendes del todo, en esta publicación tratare de darte información acerca de este tema, para que puedas comprender como y cuando usarlo.
Todo empieza con el documento de Roy Fielding en el que plasma sus ideas, en el que tenia como objetivo mejorar la conexión de sistemas interconectados distribuidos. Antes de este documento, se buscaba como interconectar sistemas no homogéneos. ya que antes de REST las opciones más populares eran SOAP y XML-RPC.
¿Qué es Rest y Restfull?
En términos simples REST, Lo podríamos definir con los siguientes terminos:
- un estilo y diseño de arquitectura de software basado en redes
- es un estilo de arquitectura para sistemas distribuidos
- es un estilo de arquitectura para ayudar a crear y organizar sistemas distribuidos
la palabra clave en estas definiciones es estilo, porque un aspecto importante de REST es que es un estilo no una guía, no un estándar, o algo que implique reglas a seguir para tener una arquitectura definida. ademas aquellas arquitecturas que cumplan con los principios REST reciben el nombre RESTFull.
La Idea de REST detrás de los sistemas distribuidos es mejorar las siguientes Areas:
- Rendimiento, plantea ser eficiente y simple permitiendo ser rápidos a los sistemas que lo implementen
- Escalabilidad de interacción de componentes
- simplicidad de interface, permitir una interfaz simple entre sistemas que da las ventajas previas
- Componentes Modificables, permitiendo la independencia de cada componente
- Portabilidad. puede ser implementado o usado en cualquier tecnología.
- Disponibilidad.
- Visibilidad.
Consideraciones de Rest:
- No es Nuevo. términos como cloud computing o servicios feed de dispositivos moviles nos hace pensar que REST es nuevo, pero lo cierto es de que se definio en el año 2000.
- El que hallas creado un sistema que use HTTP y JSON no significa que sea un sistema RestFull
En 1999 una petición fue enviada al IETF, via RFC 2616. uno de sus autores, Roy Fielding definio un conjunto de principios al rededor de HTTP y URI. dando inicio a REST.
Principios REST
Principio 1 - todo es un recurso
para entender este concepto se debe considerar a los datos como formatos específicos y no como archivos físicos. cada dato en la Internet tiene un formato que define su tipo de contenido(Content-type). Por Ejemplo los siguientes formatos se representan de la siguiente manera:
- JPEG, image/jpeg
- MPEG video, video/mpeg
- HTML, text/html
- XML, text/xml
- Documentos de texto, application/octet-stream
Principio 2 - cada recurso es identificable por un identificador único
debido a que e la Internet existen diferente recursos, cada uno deberia tener una dirección única URI ademas que debería tener formato legible. por ejemplo:
- http://www.faztweb.com/images/vacation/2017/summer, estos recursos son imagenes
- http://www.faztweb.com/videos/vacation/2017/summer, estos recursos son videos
- http://www.faztweb.com/data/documents/balance?format=xml/summer, estos recursos son documentos xml
- http://www.faztweb.com/data/archives/2017, estos recursos son algún documentos o archivos binario
Principio 3 - usa los métodos HTTP estándar
Los protocolos nativos HTTP(RFC 2616) define ocho acciones también conocidas como verbos: GET, POST, PUT, DELETE, HEAD, OPTIONS, TRACE, CONNECT.
Para entenderlos podemos hacer un simil con un CRUD de la aplicaciones:
- GET, pidiendo un recurso existente.
- POST, crea un recurso.
- PUT, crea o actualizar un recurso.
- DELETE, elimina un recurso existente.
Principio 4 - recursos pueden tener múltiples representaciones
una de las características claves es poder representar un recurso en multiples formatos, es decir un servidor puede devolver un recurso tan en xml, como en json.
Principio 5 - communication Statelessly, comunicación sin estado
la manipulacion de recursos sobre http deberia ser considerado atomico. todas las modificaciones deben ser a través de peticiones HTTP..
Comentarios
Publicar un comentario