PARTE I: DOMINA EL DISEÑO DE UNA API
PARTE II: ARQUITECTURAS Y CONTROLADORES API
LABORATORIOS ¡Aplica ya! : DISEÑO Y VARIANTES API CON INMEMORY Y SQL SERVER

¿Cómo funciona una API?

   Después de esta lección

Aprenderás a:

  • Reconocer la arquitectura general de una API.

Cursos Institucionales.
El Aprendizaje Hecho Fácil. ¡Disfrútalo!

   Laboratorios ¡Aplica ya!


El material teórico de las lecciones se aplica en los videos tutoriales del curso.

Arquitectura de una API


En la siguiente ilustración se deescribe la arquitectura general de una API REST, que utilizaremos ámpliamente durante el curso.

APIS - REST - EASY TO MAKE 0

Explicación:

  1. El usuario realiza una solicitud desde su aplicación Cliente la cual contiene una implementación API REST.
  2. La Web API o Servicio gestiona la petición a través del Controlador que la recepciona desde la Vista o navegador del usuario (Cliente). Dependiendo de la solicitud ejecuta el ActionResult que para el caso del ejemplo se llamaría estudiante que tramita la peticións con el método asignado al verbo Http Get por ser una consulta de datos.
  3. La API REST crea una URI (Uniform Resource Identifier). El puerto puede o no ser desplegado. En este caso el usuario está requiriendo el recurso resource estudiante, usando un parámetro id  cuyo código es ’77’.

    El formato general es:
    {protocolo}://{hostname}:{puerto}/{ruta del recurso}?{parámetros de filtrado (opcional)}

    Por ejemplo, si el usuario solicitara un estudiante en particular con el código ’77’:
    Https://100.1.1.0:800/Estudiante/?IDEstudiante=77

  4. Ahora la transmisión de datos utiliza los métodos estándar del protocolo HTTP para responder response la solicitud request del cliente:
    El mensaje de respuesta incluye:
    –  Los encabezados y los parámetros con la información de identificación importante con respecto a los metadatos,
    –   La autorización,
    –   El identificador uniforme de recursos (URI),
    –   El almacenamiento en caché,
    –   Las cookies y otros elementos de la solicitud.
    Hay encabezados de solicitud y de respuesta, pero cada uno tiene sus propios códigos de estado e información de conexión HTTP Red hat 
  5. Una vez el servidor ha ubicado el recurso responde de vuelta la solicitud con el mensaje basado en el protocolo HTTP, enviando además un código por ejemplo 200 para indicar que la solicitud fue exitosa.
  6.  La aplicación deserializa nuevamente los datos y los despliega el resultdado de datos en la navegador del usuario.

  Los mensajeros entre aplicaciones son las APIs: reciben la solicitud del servicio, traducen el mensaje y retornan la respuesta.

Los formatos JSON y XML serán tratados en lecciones porteriores.

Peticiones (request)

Las peticiones realizadas por el usuario forman parte del CRUD relacionado con los verbos HTTP:

  1. Create: nuevo registro -> POST
  2. Read: Leer, obtener, solicitar un registro -> GET
  3. Update: actualizar un registro -> PUT
  4. Delete: Eliminar un registro -> DELETE
EJEMPLO DE UNA PETICIÓN:

POST /estudiante HTTP/1.1
Content-Type: application/xml

<estudiante>
   <nombre>Veronica Brown</nombre>
   <fecha>Diciembre 1, 2050 09:43</fecha>
   ...
</estudiante> 

Explicación:
En el ejemplo encontramos el verbo/método Post como parte de operación en la petición del usuario (cliente) para crear un estudiante. La versión del protocolo HTTP y la cabecera de la petición. Además se especifica el formato de los datos con xml, para este caso.

Las cabeceras (en inglés headers) HTTP permiten al cliente y al servidor enviar información adicional junto a una petición o respuesta. Una cabecera de petición esta compuesta por su nombre (no sensible a las mayúsculas) seguido de dos puntos ‘:‘, y a continuación su valor (sin saltos de línea). Los espacios en blanco a la izquierda del valor son ignorados Mozilla

Respuesta (response)

Ahora el servidor recibe el mensaje Post, gestiona la petición en formato xml y registra un nuevo registro. Finalmente devolvería una respuesta como la siguiente:

HTTP/1.1 201 Created
Content-Type: application/xml
Location: http://easytomake.net/estudiante/777

<estudiante id="777">
    <link rel="self" hhttp://easytomake.net/estudiante/777/>
    <nombre>Veronoica Brown</nombre>
    <fecha>Diciembre 1, 2050 09:43</fecha>
    ...
</estudiante> 

Observa que el servidor ha enviado en la cabecera del mensaje el código HTTP 201 para indicar que el estudiante relacionado en la petición ha sido creado.

   URIs en API REST

Siempre que sea posible, los URI de recursos deben basarse en nombres (el recurso) y no en verbos (las operaciones en el recurso).

Ejemplo de una URI diseñada correctamente:
https:// easytomake.net / api / estudiantes

Ejemplo de una URI diseñada incorrectamente:
https:// easytomake.net / api / CrearEstudiantes

Las URI serán ampliamente tratadas en los laboratorios del curso.

 

APLICA YA! - Easy To MakeEasy interactivo. ¡Inténtalo!


Afina tus conocimientos con el siguiente repaso interactivo. Puedes repasar o regresas al soporte teórico las veces que necesites.