REST Web API
La tecnología del desarrollo de sistemas informáticos varía y evoluciona a una velocidad impresionante. De la programación estructurada, la programación visual a los conceptos actuales de servicios web, API (Application Programming Interface) y REST (Representational State Transfer). Actualmente en aplicaciones o sitios web hoy, lo más común es hablar de REST y .NET Web API. A menos que estés usando esas tecnologías si están en el ámbito de la informática. La mejor forma de entender las cosas es usarlas en forma práctica.
En un esquema de integración de aplicación tradicional cada aplicación cliente tiene su propia lógica de negocios (probablemente programada en varios leguajes diferentes) que se conecta directamente a la base de datos para obtener, actualizar y manipular datos.
Esta lógica de negocios local significa que las aplicaciones del cliente pueden volverse complejas fácilmente y todas deben mantenerse sincronizadas entre sí. Cuando se requiera una nueva característica, deberá actualizar cada aplicación en consecuencia. Este puede ser un proceso muy costoso que a menudo conduce a la fragmentación de las características, errores y realmente puede retrasar la innovación.
Ahora analicemos la misma arquitectura con una API centralizada que contiene toda la lógica de negocio.
La Arquitectura REST modera sigue el concepto de Don’t Repeat Yourself’ (DRY) No repetir el proceso' (DRY) de desarrollo de software. Las aplicaciones se convierten en capas de interfaz de usuario relativamente livianas. REST es un patrón arquitectónico para crear una API que usa HTTP como su método de comunicación subyacente.
Casi todos los dispositivos que están conectados a Internet ya usan HTTP; es el protocolo base sobre el que se basa Internet, y por eso es una gran plataforma para una API.
HTTP es un sistema de solicitud y respuesta; un cliente llamante envía una solicitud a un punto final y el punto final responde. El cliente y el punto final pueden ser cualquier cosa menos un ejemplo típico es un navegador que accede a un servidor web o a una aplicación que accede y API.
Hay varios detalles clave de implementación con HTTP que debe tener en cuenta:
Recursos: REST usa recursos direccionables para definir la estructura de la API.
Un identificador de recursos uniforme (URI) es o bien un localizador uniforme de recursos (URL), como también un nombre de recurso uniforme (URN), o ambos a la vez.
Esta lógica de negocios local significa que las aplicaciones del cliente pueden volverse complejas fácilmente y todas deben mantenerse sincronizadas entre sí. Cuando se requiera una nueva característica, deberá actualizar cada aplicación en consecuencia. Este puede ser un proceso muy costoso que a menudo conduce a la fragmentación de las características, errores y realmente puede retrasar la innovación.
Ahora analicemos la misma arquitectura con una API centralizada que contiene toda la lógica de negocio.
La Arquitectura REST modera sigue el concepto de Don’t Repeat Yourself’ (DRY) No repetir el proceso' (DRY) de desarrollo de software. Las aplicaciones se convierten en capas de interfaz de usuario relativamente livianas. REST es un patrón arquitectónico para crear una API que usa HTTP como su método de comunicación subyacente.
REST fue originalmente concebido por Roy Fielding en su trabajo de disertación de 2000 titulado 'Estilos arquitectónicos y el diseño de arquitecturas de software basadas en red', les recomiendo ver ese artículo en el siguiente link:
Casi todos los dispositivos que están conectados a Internet ya usan HTTP; es el protocolo base sobre el que se basa Internet, y por eso es una gran plataforma para una API.
HTTP es un sistema de solicitud y respuesta; un cliente llamante envía una solicitud a un punto final y el punto final responde. El cliente y el punto final pueden ser cualquier cosa menos un ejemplo típico es un navegador que accede a un servidor web o a una aplicación que accede y API.
Hay varios detalles clave de implementación con HTTP que debe tener en cuenta:
Recursos: REST usa recursos direccionables para definir la estructura de la API.
Estas son las URL que usa para llegar a las páginas en la web,
por ejemplo 'http://www.microsoft.com/Surface-Pro-3' es un recurso.
Acciones de solicitud: describen lo que quiere hacer con el recurso.
Un navegador típicamente emite un
- GET para obtener un recurso del servidor
- POST para crear un recurso del servidor, envía datos a una URL para que el recurso en esa URI los maneje.
- PUT para actualizar un recurso del servidor, pone un recurso en la dirección especificada en la URL. Exactamente en esa dirección. Si no existe, lo crea, si existe lo reemplaza.
- DELETE para eliminar un recurso del servidor
La lista completa en http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
En el contexto de una API REST, los recursos normalmente representan entidades de datos (es decir, 'Paciente', 'Profesional', 'Orden', etc.). El verbo que se envía con la solicitud informa a la API qué hacer con el recurso, por ejemplo, una solicitud GET obtiene datos sobre una entidad, las solicitudes POST crean una nueva entidad.
Existe una convención que establece que las solicitudes GET a una url de la entidad, como Pacientes, devuelve una lista de Pacientes , posiblemente coincida con algunos criterios que se enviaron con la solicitud. Sin embargo, para recuperar un Paiente específico, usaría la identificación del Paciente como parte del recurso.
Por ejemplo
/ Paciente / 81 devolvería el Paciente con la ID de 81.
También es posible usar parámetros de cadena de consulta con una API, por ejemplo puede tener algo como / Paciente? Sexo= Femenino que devuelve todos los Pacientes femeninos.
La Web API utiliza los conceptos de Controlador y Acción de MVC ( Model View Controller) , por lo que si ya entiende .net MVC, se encuentra en un buen lugar. Si no lo hace, entonces la API web es una excelente forma de aprender MVC.
La API web usa el motor de enrutamiento .net para asignar direcciones URL a los controladores. Normalmente, las API se mantienen dentro de una ruta '/ api /' que ayuda a distinguir los controladores API de otras API que no pertenecen al mismo sitio web.
Las acciones se utilizan para mapear verbos HTTP específicos, por ejemplo, normalmente tendrías una acción GET que devuelve todas las entidades.
Web API es parte de 'One ASP.net'
Web API es parte de la familia 'One ASP.net', lo que significa que admite de forma nativa todas las excelentes funciones compartidas que puede usar actualmente con MVC o formularios web, esto incluye (estos son solo algunos ejemplos):
- Entity Framework, (Marco de la entidad).
- Authorisation and identity, (Autorización e identidad).
- Scaffolding, (Andamiaje).
- Routing, (Enrutamiento).
REST es un patrón arquitectónico que se basa en HTTP y utiliza solicitudes HTTP, respuestas, verbos y códigos de estado para comunicarse. El hecho de que los servicios REST usen HTTP significa que pueden ser consumidos por casi cualquier dispositivo o aplicación "en línea" (incluidos dispositivos IoT como tostadoras, automóviles, podómetros, etc.). No se requiere conocimiento propietario de la API.
Web API en .net es la forma en que escribes los servicios de API REST en .NET. Web API le ofrece todos los beneficios del .NET Framework y se ocupa de muchas de las complejidades de la negociación de contenido, el enlace de modelos, etc. que tendría que tratar usted mismo sin Web API.
Referencias
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
http://www.microsoft.com/Surface-Pro-3
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
https://restfulapi.net/rest-put-vs-post/
http://notasjs.blogspot.com/2013/07/
http-diferencia-entre-post-y-put.html
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
http://www.microsoft.com/Surface-Pro-3
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
https://restfulapi.net/rest-put-vs-post/
http://notasjs.blogspot.com/2013/07/
http-diferencia-entre-post-y-put.html
Comentarios
Publicar un comentario