Cursos Empresas Blog Live Conf Precios

¿Qué es REST?

Clase 4 de 22 • Curso de APIs con .NET

Clase anteriorSiguiente clase

Joaquin Ignacio Mardones Muñoz

student•

Asincrónicos:

API: Application Programming Interface Rest : Representational State Transfer

Respuestas HTTP: Informativas : 100-199 Satisfactorias : 200-299 Se insertó bien 201 Se realizó bien el proceso pero no cuenta con nada para responder : 204 Redirecciones : 300-399 Error Cliente : 400-499 Error Server : 500-599

Miguel Teheran

teacher•

Excelente resumen. Siempre recordar que estos códigos son genericos y aplican para todas las tecnologias el patron REST es generico.

Platzi Team

student•

¿Qué es REST?

REST es un acrónimo que significa "***Representational State Transfer***". Es un estilo de arquitectura de software que se utiliza para desarrollar aplicaciones en la web.

REST es una forma estándar de crear APIs, y se basa en la utilización de protocolos HTTP (Hypertext Transfer Protocol) para realizar operaciones CRUD (Create, Read, Update, Delete) en recursos web. En otras palabras, REST utiliza los verbos HTTP (como GET, POST, PUT y DELETE) para realizar operaciones en los recursos web.

Contiene las siguientes propiedades:

Rendimiento
Simplicidad
Escalabilidad
Confialidad

<aside> <img src="https://static.platzi.com/media/achievements/piezas-apis-net_badge-c406370c-4162-4596-8184-78641fd19953.png" alt="https://static.platzi.com/media/achievements/piezas-apis-net_badge-c406370c-4162-4596-8184-78641fd19953.png" width="40px" /> El objetivo de REST es proporcionar una forma uniforme de acceder a los recursos web y hacer que la información sea accesible desde cualquier lugar, a través de una red, como Internet. REST es una alternativa a otros protocolos como SOAP (Simple Object Access Protocol) y es conocido por ser una forma más simple, flexible y escalable de crear APIs. </aside>

URL

Una URL en una API REST debe tener las siguientes propiedades:

Clarity: La URL debe ser clara y fácil de leer para que sea fácil de entender para los desarrolladores que la utilizan.
Identificación de recursos: La URL debe identificar de manera clara y concisa el recurso que se está solicitando.
Hierarchía: La URL debe ser un reflejo de la estructura jerárquica de los recursos, lo que permite una fácil navegación.
Consistencia: La URL debe ser consistente a lo largo de toda la API y seguir un estándar claro para que sea fácil de seguir.
Accesibilidad: La URL debe ser accesible para los clientes que utilizan la API, lo que significa que debe ser fácil de recordar y de escribir.
Evitación de duplicados: La URL debe ser única y evitar la duplicación de recursos para evitar confusiones.
Selección de verbo HTTP adecuado: La URL debe reflejar el verbo HTTP que se utiliza para la solicitud, por ejemplo, utilizar "GET /recursos" para recuperar una lista de recursos.

Estas propiedades son importantes para asegurar que la API sea fácil de usar y mantener, y para mejorar la experiencia de los desarrolladores que la utilizan. Al cumplir con estas propiedades, la API será más eficiente y escalable, y será más fácil de integrar con otros sistemas.

Verbos Http

HTTP es un protocolo utilizado para transferir información en la web, y los verbos HTTP son los comandos utilizados para solicitar una acción en un recurso en la web. Los verbos HTTP más comunes son los siguientes:

GET: utilizado para recuperar información de un recurso. Este es el verbo HTTP más utilizado y es utilizado para recuperar información de una página web o un API.
POST: utilizado para enviar información a un recurso para que sea procesada. Por ejemplo, cuando se envía un formulario en una página web, se utiliza el verbo POST para enviar los datos del formulario al servidor.
PUT: utilizado para actualizar un recurso existente. Por ejemplo, si desea actualizar la información de un producto en una base de datos, utilizaría el verbo PUT para enviar la nueva información al servidor.
DELETE: utilizado para eliminar un recurso. Por ejemplo, si desea eliminar un producto de una base de datos, utilizaría el verbo DELETE para enviar una solicitud al servidor para que lo elimine.
HEAD: utilizado para recuperar la cabecera de un recurso sin la respuesta completa.
PATCH: utilizado para actualizar parcialmente un recurso existente. Por ejemplo, si desea actualizar solo algunos campos de un producto en una base de datos, utilizaría el verbo PATCH para enviar la información actualizada al servidor.

Respuestas Http

Las respuestas HTTP son mensajes que se envían desde un servidor web a un cliente (como un navegador web o una aplicación) después de haber recibido una solicitud HTTP. Cada respuesta HTTP incluye un código de estado que indica el resultado de la solicitud.

Algunos de los códigos de estado HTTP más comunes son los siguientes:

200 OK: Indica que la solicitud HTTP se ha realizado correctamente y el servidor ha devuelto la información solicitada.
201 Created: Indica que se ha creado un recurso nuevo en el servidor como resultado de la solicitud HTTP.
204 No Content: Indica que la solicitud HTTP se ha procesado correctamente, pero no hay ninguna información que devolver.
400 Bad Request: Indica que la solicitud HTTP no es válida y el servidor no puede procesarla.
401 Unauthorized: Indica que la solicitud requiere autenticación y el cliente no proporcionó credenciales válidas.
403 Forbidden: Indica que el cliente no tiene permisos para acceder al recurso solicitado.
404 Not Found: Indica que el servidor no pudo encontrar el recurso solicitado.
500 Internal Server Error: Indica que ha ocurrido un error en el servidor y no se pudo procesar la solicitud HTTP.

Estos son solo algunos de los códigos de estado HTTP más comunes, pero hay muchos otros. Al trabajar con APIs REST, es importante comprender los códigos de estado HTTP y cómo utilizarlos para determinar el resultado de las solicitudes HTTP y tomar las acciones apropiadas en consecuencia.

Edgar napoles soriano

student•

Protocolo de transferencia de hipertexto (HTTP/1.1): semántica y contenido

https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.13

Robert Valdez Matos

student•

Comparto también una lista de HTTP Verbs adicionales a la lista de la clase: https://developer.mozilla.org/es/docs/Web/HTTP/Methods

Marcos Avila Rodriguez

student•

Respuestas HTTP

_Informativas _ 100-199 Satisfactorias 200-299 Redirecciones 300-399 Error Cliente 400-499 Error Server 500-599

Dual.william.may

student•

Get: permite obtener y leer recursos. ¿Qué es recurso a qué se le llama?

Miguel Teheran

teacher•

Cualquier cosa que se puede obtener desde el servidor de acuerdo a tu negocio, hablamos de datos de la base de datos, archivos, logs, etc...

Antonio García

student•

REST -> Estándar,

REPRESENTATIONAL STATE TRANSFER

Características:

Estilo de arquitectura para el diseño de interfaces
Permite el manejo de recursos del lado del servidor
Sus propiedad: Rendimiento, simplicidad, confiabilidad

Rest es un patron que ya esta validado, una de las reglas es que tiene VERBS: GET, POST, PUT, PATCH, DELETE.
Rest nos dice que debemos manejar una URL por cada recurso que tengamos, debe ser diciente.

Respuestas HTTP

Informativas: 100-199
Satisfactorias: 200-299
Redirecciones: 300-399
Errores de clientes: 400-499
Error de servidor: 500-599

Juan Pablo Meza Gazabón

student•

https://http.cat/

Hans González

student•

otra respuesta http es la 401:no autorizado, esto sirve cuando no se tiene la autorización para ver ese endpoint o uri

Juan Camilo Duque Gil

student•

Cuál es la diferencia entre un error de cliente y un error de servidor, es decir:

¿Cuándo nos referimos a clientes, que es exactamente una persona que consume el servicio o la aplicación que utilizaros como medio para entregar nuestra solicitud?

Andres Villanueva Tabares

student••

Cliente es la persona que hace la request y Servidor es el que responde.

Y la diferencia es del origen, o sea si es por el lado del cliente, es porque está haciendo solicitudes incorrectas o no tiene permisos para acceder a esa información, modificarla o eliminara y el servidor responde acorde a esas situaciones (400 - 499)

y cuando ocurre del lado del servidor, es que el cliente hizo la solicitud correcta, pero por alguna razón el servidor no respondió como debía o tenía fallos, o sea que el cliente no tiene culpa y el servidor no responde (500 - 599)

Manuel Fernando Jamaica Prieto

student•

el manejo de las URL por recurso facilita la gestión del recurso creado, y no interfiere con los demás lo que nos puede ayudar en cuanto a la detección de errores