TABLA DE CONTENIDO

API ....................................................................................................................................................................... 6
DEFINICIÓN ..................................................................................................................................................................... 6
FORMATOS DE APIS ........................................................................................................................................................ 8
API TESTING .................................................................................................................................................................... 9
• ¿QUE DEBEN DARME PARA PODER TESTEAR UNA API?.............................................................................. 10
• ESTRATEGIAS DE API AUTOMATION ¿QUE TESTEAR Y CÓMO? .................................................................. 10
• VENTAJAS DE HACER API AUTOMATION TESTING ...................................................................................... 11
• HERRAMIENTAS PARA HACER API AUTOMATION TESTING ........................................................................ 11
• BUENAS PRACTICAS ..................................................................................................................................... 12
• AUTOMATIZACIÓN UI VS API ¿CUÁL HACER Y POR QUÉ? ........................................................................... 13
o CONCLUSIONES........................................................................................................................................ 16
ELEMENTOS QUE COMPONEN A UNA PETICIÓN O REQUEST ................................................................................ 17
REQUEST ....................................................................................................................................................................... 17
HEADERS/COOKIES ....................................................................................................................................................... 17
ENDPOINT ..................................................................................................................................................................... 17
RESOURCES O RECURSOS ............................................................................................................................................. 17
PARAMETERS O PARÁMETROS ..................................................................................................................................... 18
• PATH PARAMETERS ..................................................................................................................................... 18
• QUERY PARAMETERS ................................................................................................................................... 18
RESPONSE ..................................................................................................................................................................... 18
SERVICIOS WEB .................................................................................................................................................. 19
DEFINICIÓN ................................................................................................................................................................... 19
CARACTERÍSTICAS DE LOS SERVICIOS WEB .................................................................................................................. 19
¿CÓMO FUNCIONA UN SERVICIO WEB?....................................................................................................................... 19
PROCESO DEL FUNCIONAMIENTO DE UN SERVICIO WEB ............................................................................................ 20
ESTRUCTURA DE UN SERVICIO WEB ............................................................................................................................. 20
EJEMPLOS DE SERVICIOS WEB ...................................................................................................................................... 21
• AMAZON WEB SERVICES ............................................................................................................................. 21
• GOOGLE ....................................................................................................................................................... 21
• T-MOBILE ..................................................................................................................................................... 22
VENTAJAS Y DESVENTAJAS DE UN WEB SERVICE ......................................................................................................... 23
• VENTAJAS..................................................................................................................................................... 23
o INTEROPERABILIDAD ............................................................................................................................... 23
o OMNIPRESENCIA...................................................................................................................................... 23

1
 o BAJA COMPLEJIDAD ................................................................................................................................. 23
o SOPORTE .................................................................................................................................................. 23
• DESVENTAJAS .............................................................................................................................................. 24
o SEGURIDAD .............................................................................................................................................. 24
o TRANSACCIONES ...................................................................................................................................... 24
o EFICACIA .................................................................................................................................................. 24
o VELOCIDAD .............................................................................................................................................. 24
API REST ........................................................................................................................................................................ 25
• ¿QUE DEBO SABER AL DESARROLLAR UNA API REST? ................................................................................ 26
SOAP ............................................................................................................................................................................. 27
• WSDL............................................................................................................................................................ 27
• DIFERENCIAS ENTRE SOAP Y WSDL ............................................................................................................. 27
DIFERENCIAS SOAP Y REST............................................................................................................................................ 28
• SOAP ............................................................................................................................................................ 28
• REST ............................................................................................................................................................. 28
AUTENTICACIÓN ................................................................................................................................................. 29
DEFINICIÓN ................................................................................................................................................................... 29
BASIC AUTH .................................................................................................................................................................. 29
BEARER MEDIANTE TOKEN ........................................................................................................................................... 29
OAUTH .......................................................................................................................................................................... 29
HAWK AUNTHETICATION ............................................................................................................................................. 29
MÉTODOS HTTP .................................................................................................................................................. 30
DEFINICIÓN ................................................................................................................................................................... 30
GET ................................................................................................................................................................................ 30
POST.............................................................................................................................................................................. 30
PUT................................................................................................................................................................................ 30
PATCH ........................................................................................................................................................................... 30
DELETE .......................................................................................................................................................................... 30
HEAD ............................................................................................................................................................................. 31
OPTIONS ....................................................................................................................................................................... 31
TRACE............................................................................................................................................................................ 31
IDEMPOTENCIA ............................................................................................................................................................. 31
CÓDIGOS DE ESTADO HTTP ................................................................................................................................. 32
DEFINICIÓN ................................................................................................................................................................... 32
1XX RESPUESTAS INFORMATIVAS ................................................................................................................................ 33
• 100 CONTINUE ............................................................................................................................................. 33
• 101 SWITCHING PROTOCOL ........................................................................................................................ 33
2
 • 102 PROCESSING (WEBDAV) ....................................................................................................................... 33
• 103 EARLY HINTS (EN-US) ............................................................................................................................ 33
2XX PETICIONES CORRECTAS (TODO SALIÓ BIEN) ........................................................................................................ 34
• 200 OK (CÓDIGO COMÚN)........................................................................................................................... 34
• 201 CREATED ............................................................................................................................................... 34
• 202 ACCEPTED ............................................................................................................................................. 34
• 203 NON-AUTHORITATIVE INFORMATION.................................................................................................. 34
• 204 NO CONTENT (EN-US) ........................................................................................................................... 34
• 205 RESET CONTENT (EN-US) ...................................................................................................................... 34
• 206 PARTIAL CONTENT ................................................................................................................................ 35
• 207 MULTI-STATUS (WEBDAV) .................................................................................................................... 35
• 208 MULTI-STATUS (WEBDAV) .................................................................................................................... 35
• 226 IM USED (HTTP DELTA ENCODING) ...................................................................................................... 35
3XX REDIRECCIONES (CUANDO SE CARGA OTRO RECURSO)........................................................................................ 36
• 300 MULTIPLE CHOICE (EN-US) ................................................................................................................... 36
• 301 MOVED PERMANENTLY (CÓDIGO COMÚN) ......................................................................................... 36
• 302 FOUND .................................................................................................................................................. 36
• 303 SEE OTHER (EN-US) (CÓDIGO COMÚN) ................................................................................................ 36
• 304 NOT MODIFIED ..................................................................................................................................... 36
• 305 USE PROXY ............................................................................................................................................ 36
• 306 UNUSED ................................................................................................................................................ 37
• 307 TEMPORARY REDIRECT (EN-US) ........................................................................................................... 37
• 308 PERMANENT REDIRECT (EN-US) ........................................................................................................... 37
4XX ERRORES DEL CLIENTE (ÓSEA DE NOSOTROS)....................................................................................................... 38
• 400 BAD REQUEST (CÓDIGO COMÚN) ........................................................................................................ 38
• 401 UNAUTHORIZED (CÓDIGO COMÚN) ..................................................................................................... 38
• 402 PAYMENT REQUIRED ............................................................................................................................ 38
• 403 FORBIDDEN (CÓDIGO COMÚN) ............................................................................................................ 38
• 404 NOT FOUND (CÓDIGO COMÚN) ........................................................................................................... 38
• 405 METHOD NOT ALLOWED (EN-US) (CÓDIGO COMÚN) .......................................................................... 38
• 406 NOT ACCEPTABLE (EN-US) .................................................................................................................... 38
• 407 PROXY AUTHENTICATION REQUIRED (EN-US) (CÓDIGO COMÚN) ....................................................... 39
• 408 REQUEST TIMEOUT (CÓDIGO COMÚN) ................................................................................................ 39
• 409 CONFLICT (EN-US) ................................................................................................................................. 39
• 410 GONE (EN-US) ....................................................................................................................................... 39
• 411 LENGTH REQUIRED (EN-US) .................................................................................................................. 39

3
 • 412 PRECONDITION FAILED (EN-US) ........................................................................................................... 39
• 413 PAYLOAD TOO LARGE ........................................................................................................................... 39
• 414 URI TOO LONG (EN-US)......................................................................................................................... 39
• 415 UNSUPPORTED MEDIA TYPE (EN-US) ................................................................................................... 39
• 416 REQUESTED RANGE NOT SATISFIABLE (EN-US) .................................................................................... 40
• 417 EXPECTATION FAILED (EN-US) .............................................................................................................. 40
• 418 I'M A TEAPOT ........................................................................................................................................ 40
• 421 MISDIRECTED REQUEST ........................................................................................................................ 40
• 422 UNPROCESSABLE ENTITY (EN-US) (WEBDAV)....................................................................................... 40
• 423 LOCKED (WEBDAV) ............................................................................................................................... 40
• 424 FAILED DEPENDENCY (WEBDAV) .......................................................................................................... 40
• 426 UPGRADE REQUIRED (EN-US) ............................................................................................................... 40
• 428 PRECONDITION REQUIRED (EN-US) ...................................................................................................... 40
• 429 TOO MANY REQUESTS (EN-US)............................................................................................................. 41
• 431 REQUEST HEADER FIELDS TOO LARGE (EN-US) .................................................................................... 41
• 451 UNAVAILABLE FOR LEGAL REASONS (EN-US) ....................................................................................... 41
5XX ERRORES DEL SERVIDOR ........................................................................................................................................ 42
• 500 INTERNAL SERVER ERROR (CÓDIGO COMÚN) ...................................................................................... 42
• 501 NOT IMPLEMENTED (EN-US) ................................................................................................................ 42
• 502 BAD GATEWAY (CÓDIGO COMÚN) ....................................................................................................... 42
• 503 SERVICE UNAVAILABLE (CÓDIGO COMÚN) .......................................................................................... 42
• 504 GATEWAY TIMEOUT ............................................................................................................................. 42
• 505 HTTP VERSION NOT SUPPORTED .......................................................................................................... 42
• 506 VARIANT ALSO NEGOTIATES (EN-US) ................................................................................................... 43
• 507 INSUFFICIENT STORAGE (EN-US) .......................................................................................................... 43
• 508 LOOP DETECTED (EN-US) (WEBDAV) .................................................................................................... 43
• 510 NOT EXTENDED (EN-US) ....................................................................................................................... 43
• 511 NETWORK AUTHENTICATION REQUIRED (EN-US) ................................................................................ 43
JSON .................................................................................................................................................................. 44
DEFINICIÓN ................................................................................................................................................................... 44
DATOS DE JSON ............................................................................................................................................................ 45
• OBJETO ........................................................................................................................................................ 45
• NÚMERO ...................................................................................................................................................... 45
• VALOR .......................................................................................................................................................... 46
• LOS ESPACIOS EN BLANCO .......................................................................................................................... 46
• ARREGLO ...................................................................................................................................................... 47

4
 • CADENA DE CARACTERES ............................................................................................................................ 47
FORMATO ..................................................................................................................................................................... 48
• ARREGLOS DE DATOS .................................................................................................................................. 48
• VARIABLES DINÁMICAS................................................................................................................................ 49
JASON PATH .................................................................................................................................................................. 50
• ACCEDER AL VALOR DE UN PARÁMETRO PRINCIPAL .................................................................................. 51
• ACCEDER AL VALOR DE UN ARREGLO.......................................................................................................... 51
• ACCEDER AL VALOR DEL PARÁMETRO DE UN OBJETO................................................................................ 52
PROXY ................................................................................................................................................................ 53
DEFINICIÓN ................................................................................................................................................................... 53
• ¿PARA QUE SIRVE UN SERVIDOR PROXY? ................................................................................................... 54
PROXY INVERSO ............................................................................................................................................................ 54
PROXY PARA TODOS ..................................................................................................................................................... 55
SECURITY TESTING .............................................................................................................................................. 56
SQL INJECTION .............................................................................................................................................................. 56
FUZZING SCAN .............................................................................................................................................................. 56
XPATH INJECTION ......................................................................................................................................................... 57
INVALID TYPES .............................................................................................................................................................. 58
BOUNDARY SCAN.......................................................................................................................................................... 59
MALFORMED XML ........................................................................................................................................................ 59
XML BOMB.................................................................................................................................................................... 60
CROSS SITE SCRIPTING .................................................................................................................................................. 61
MALICIOUS ATTACHMENT............................................................................................................................................ 61
PREGUNTAS DE ENTREVISTA ............................................................................................................................... 62
OTROS ................................................................................................................................................................ 64
TÉRMINOS .......................................................................................................................................................... 65

5
 API

DEFINICIÓN

• Significa Application Programming Interface.

• Es una interfaz o protocolo de comunicación entre el cliente y el servidor, hecho para simplificar la creación
de software del lado del cliente.
• Una API representa la capacidad de comunicación entre componentes de software.
• Para entenderlo mejor, es como un tomacorrientes, que al conectarle algún aparato y dependiendo de su
amperaje y voltaje, el aparato espera una energía para funcionar.
• Sirven para conectar el FrontEnd con el BackEnd.
• Las pruebas API son buenas porque:
o La cobertura puede ser mucho mayor.
o Puedo probar muchas cosas a nivel de datos, de entradas.
o Puedo reutilizar estas pruebas para crear datos, que puedan alimentar la prueba a nivel de FrontEnd.

• Son interfaces, para que programas de software se comuniquen entre ellos y compartan datos bajo ciertos
estándares; el más usado hoy en día es REST y el formato más usado para enviar datos es JSON.
o JSON: Significa JavaScript Object Notation.
▪ Es un formato para transferir información.

• Son servicios normalmente web que nos ofrece una empresa o nosotros mismos, y que, como no tiene una
interfaz de usuario la única forma de probarlo es con una herramienta que llame a esas API para ver si
realmente responden a los requerimientos que nosotros necesitamos.
• Las APIs pueden ser públicas o privadas.
• Es una interfaz para que se comuniquen programas, aplicaciones, etc., y compartan datos entre ellos.

o INTERFAZ: Es una capa de abstracción para que dos sistemas se comuniquen.

▪ Permite que yo interactúe con un sistema, sin necesidad de saber que está pasando por
debajo.
▪ Es como manejar el volante de un carro, yo no necesito saber cómo funciona la mecánica
debajo del volante para que funcione.

o TOKEN: Cuando uno se autentica en una página la primera vez, el servidor devuelve un token.
▪ El token es un objeto que contiene todos los datos de esta autenticación.
▪ Cada vez que uno solicite información adicional, el servidor revisará si el token todavía está
vigente y ya no te pedirá una nueva autenticación.
▪ El formato más común para los tokens en APIs REST es JWT.

6
• Las APIs pueden ser:

o LOCALES: Son las que se ejecutan dentro del mismo entorno.

▪ Por ejemplo, cuando uno está desarrollando una aplicación Android y yo necesito que una
notificación haga vibrar el teléfono, entonces nos comunicamos con la API de vibración del
teléfono, donde todo ocurre de manera local.

o REMOTAS: Donde se consumen datos de una aplicación que está en otro lugar, en otro punto del
mundo.
▪ Las remotas pueden utilizar servicios web.
➢ SERVICIO WEB: Es un sistema que permite la comunicación entre equipos que estén
en una red.
❖ Estos sistemas tienen que seguir ciertos estándares, usar el protocolo HTTP
(Protocolo para navegar por internet).
❖ Es la base de las APIs remotas, de la comunicación entre programas, pero
que estén en lugares diferentes.
❖ Puede ser un Json.

▪ Si usan servicios web pueden usar el protocolo SOAP o REST:

➢ SOAP: (Simple Object Access Protocol) Es un protocolo que todavía se sigue usando,
aunque no tanto ya.

➢ REST: Es una arquitectura:

❖ ARQUITECTURA DE SOFTWARE: Es la forma en que está diseñado un

sistema, como están organizados sus componentes, como se comunican
entre ellos, que funciones cumplen, etc.
Es decir, si yo quiero que mi aplicación pueda consumirse desde
otras Apps, yo puedo definir los permisos.

❖ Las APIs pueden ser de varios tipos, uno de estos tipos es la API REST.
❖ Significa Representación de Transferencia de Estado.
❖ Es una aplicación web en el lado del Back-End.
❖ Esta arquitectura implica que:
Pueden guardarse los datos en cache.
El estado no se envía en las peticiones.
Uno puede definir qué datos permite que otra aplicación acceda,
revise o manipule.

❖ Si uno crea un servicio web usando la arquitectura REST, estamos hablando

de RESTFUL.

7
FORMATOS DE APIS

• Las APIs pueden devolver la información en diferentes formatos.

o JSON: Es el formato más común { }.

o XML: Es el formato para enviar datos que se ha usado casi siempre < >.
o TEXTO PLANO: Aa.

8
API TESTING

• Gracias a la evolución de las aplicaciones que hoy en día se integran con APIs, se hace indispensable realizar
API Testing para obtener una mayor cobertura de las pruebas y aportar mayor calidad al producto final.

• De acuerdo con la Pirámide de Automatización, API Testing es un tipo de prueba de software que está dentro
de los tipos de pruebas de integración.
• Lo que hace API Testing es validar y verificar que las funcionalidades responden correctamente, por lo que se
considera un tipo de prueba a bajo nivel, es decir, que no interactúa directamente con la interfaz de usuario.
• En el caso de que estemos probando una API REST, cuando interactuamos con un Web Services por HTTP,
¿cómo sabemos que los resultados son correctos? Básicamente, por las respuestas de los códigos de estado
cuando consultan información a la API.
• El flujo consiste en enviar los datos de entrada, la API REST la procesa y se obtiene como resultado la salida
con los siguientes códigos de respuesta:
o CÓDIGOS 200: cuando son respuestas exitosas
o CÓDIGOS 300: cuando son mensajes de redirección
o CÓDIGOS 400: cuando son errores del cliente
o CÓDIGOS 500: cuando existen problemas con el servidor

9
¿QUE DEBEN DARME PARA PODER TESTEAR UNA API?

o Para testear una API deben darme un contracto de API que sería algo como:

ESTRATEGIAS DE API AUTOMATION ¿QUE TESTEAR Y CÓMO?

o APRENDER EL COMPORTAMIENTO DE LA API: Explorar toda la documentación posible que tengamos

a la mano (Como links de la API, información que halla en la página de la API, preguntarle a
cualquiera que tenga conocimiento sobre el uso de la API, etc.)
▪ Necesitamos conocer:
➢ EndPoints que maneje la API.
➢ Headers va a necesitar.
➢ Body necesario para hacer el Request.

o VALIDAR LAS RESPUESTAS: Crear aserciones sobre la respuesta de la API.

o ¡¡NO DEPENDAN, ENCAPSULEN!!: Encapsular los test de API.

▪ Significa tratar de usar Request que no dependan de data que exista, porque a veces se va a
hacer un RollBack del servidor o de la base de datos, y los datos puede que no estén ahí.
▪ Por eso se recomienda en una prueba que se creen datos, y que se eliminen al final.

o NO OLVIDAR LOS CASOS NEGATIVOS: Se debe testear el happy path, pero también es necesario que
probemos los casos negativos.
▪ Esto sirve mucho sobre todo para temas de seguridad.

10
VENTAJAS DE HACER API AUTOMATION TESTING

o PROMUEVE EL SHIFT LEFT TESTING: No es necesario contar con el producto totalmente terminado
para comenzar a probar, basta con tener conexión a las API para ir probando sus funcionalidades.
▪ Con estas pruebas vamos a poder probar requerimientos antes de que la aplicación o el
producto existan (UI + BackEnd).

o MANTENIMIENTO SENCILLO: Al ser más sencillo que las pruebas de interfaz de usuario, lo ideal es
tener pruebas de API robustas para que las pruebas de interfaz de usuario sean solamente
preventivas.
▪ Sabemos que las pruebas de interfaz de usuario son cambiantes y hay que reescribirlas y
mantenerlas constantemente.
▪ En cambio, con las pruebas de API es poco frecuente que se produzcan cambios y en casos
que haya algún cambio es más fácil poder controlarlo.
▪ La posibilidad de que estas pruebas fallen es menor (Porque es raro que la API cambie).
▪ El mantenimiento del framework en donde tengamos las pruebas es menor.

o MAYOR VELOCIDAD DE EJECUCIÓN: ¿Sabía que es posible probar 300 pruebas de APIs en tres
minutos aproximadamente? Eso significa que existe más tiempo para corregir y más tiempo para
probar.
▪ Estas pruebas son mucho más rápidas (Porque no tocamos en ningún momento el UI, solo
mandamos un Request a un EndPoint y esperamos y validamos un Response).

o REDUCCIÓN DE ERRORES: Al estar probando y corrigiendo en una capa intermedia, van a mejorar los
resultados de las pruebas en general.

o INTEGRACIÓN DEL TRABAJO: Como testers, al probar una API se necesitará mucho apoyo de parte
del equipo de desarrollo, y, por consiguiente, uno puede conocer la parte más técnica del proyecto.

HERRAMIENTAS PARA HACER API AUTOMATION TESTING

o SOAP UI.
o Katalon Studio.
o Visual Studio.
o Test Complete.

11
BUENAS PRACTICAS

o HATEOAS: Significa que la API se autodescribe, cada recurso tiene información de cuál es el recurso
siguiente o de la cantidad de recursos totales que hay.
▪ Porque no es tan sencillo como un arreglo que el primer elemento es el índice 0 y el segundo
es el 1, porque puede que se hallan eliminado registros en el proceso y tal vez el primer
elemento sea el 0 y siguiente el 50 (Tendríamos 49 errores hasta llegar al siguiente recurso).

o SEGURIDAD: Si la API es privada debemos protegerla.

o TESTEAR: Debemos testear las APIs, testear que todo funcione correctamente.

o DOCUMENTACIÓN: El testeo está muy ligado a la documentación.

▪ Debemos documentar la API.

12
AUTOMATIZACIÓN UI VS API ¿CUÁL HACER Y POR QUÉ?

o Cuando las empresas se enfrentan a los retos de una transformación digital, la prisa frenética por
automatizar puede ser demasiado real.
o Sin embargo, antes de dar el salto, es importante entender cómo funcionan las diferentes soluciones
de automatización y las tecnologías clave que las sustentan.
o UN EJEMPLO: Los bots RPA suelen basarse en una interfaz gráfica de usuario (GUI), mientras que
HIRO se basa en una interfaz de programación de aplicaciones (API).
o Con el tiempo, una de ellas puede acelerar su éxito y la otra puede obstaculizarlo.
o A continuación, se explican las grandes diferencias entre cada interfaz y se revela cómo la
automatización a través de una API nos posiciona mejor para el crecimiento futuro.

o MAYOR VELOCIDAD: En comparación con una GUI, una integración de API puede hacer que nuestra
automatización sea más rápida.
▪ En términos de velocidad, una API opera independientemente del diseño de una pantalla,
trabajando entre aplicaciones y servidores.
▪ Los bots RPA deben navegar de una pantalla a otra, lo que puede verse afectado por la
velocidad de la aplicación subyacente.
▪ Así, por ejemplo, si un bot RPA necesita resolver un ticket de TI a través de múltiples
aplicaciones o transferir datos entre páginas web, las pantallas de carga lenta afectarán a la
velocidad del bot RPA.
▪ Restablecer una contraseña puede llevar diez minutos; con HIRO, diez segundos.

o TRANSFERENCIAS DE DATOS FIABLES: Las API pueden transferir limpiamente datos y comandos de
campo entre bastidores sin esperar a que se carguen las pantallas.
▪ Un bot RPA automatiza las tareas basándose en un diseño fijo de una interfaz gráfica de
usuario.
▪ En lugar de tomar sus propias decisiones, está programado para "Raspar la pantalla" de una
GUI para encontrar datos en el mismo campo o para hacer clic en el mismo botón en el
mismo lugar una y otra vez.
▪ Por desgracia, el diseño de una interfaz gráfica no es tan fijo ni estable.
➢ Por ejemplo, una actualización normal del software puede cambiar fácilmente la
posición de un cuadro de texto, un botón o un elemento de menú en una GUI.
➢ Como resultado, el bot RPA no sabrá dónde hacer clic o qué datos extraer y, a su vez,
se romperá.
➢ Nuestro personal de TI o un proveedor externo tendrá que arreglarlo, lo que le
costará aún más tiempo y dinero.
➢ Teniendo en cuenta este problema, el despliegue de un bot RPA suele requerir que
nuestro personal de TI lo pruebe exhaustivamente primero.

o MÁS FLEXIBILIDAD Y ADAPTABILIDAD: Una API es también una de las principales razones por las que
HIRO puede adaptarse con fluidez a los nuevos procesos de negocio.
▪ Recibe una orden de la API de un software y, a continuación, utiliza la IA avanzada para
aplicar los conocimientos adecuados para la tarea correcta o incluso variaciones de esa tarea.
▪ A medida que aprende más, puede automatizar nuevos procesos.
▪ Por el contrario, los bots RPA necesitan ser reprogramados para cada nueva tarea o volver a
ser probados para su uso con una interfaz gráfica de usuario.
▪ A menudo llamada una solución "De ayuda", la RPA le permite, en última instancia, seguir
utilizando un antiguo proceso de negocio y sistemas heredados en lugar de encontrar un
nuevo enfoque innovador.

13
o MAYOR SEGURIDAD Y CONTROL DEL USUARIO: Más allá de la velocidad y la fiabilidad, una
integración de API puede hacer que la automatización sea más segura, especialmente con
aplicaciones o sitios web que necesitan acceder a su información bancaria.
▪ Entre ellos se encuentran los servicios de pago, de gestión del dinero o de asesoramiento
sobre la carga.
▪ Cuando estos servicios utilizan raspadores de pantalla, lo hacen a través de empresas de
terceros que utilizan tus credenciales para acceder a tu cuenta bancaria desde un dominio
distinto.
▪ Para nosotros, no hay mucha supervisión o control sobre lo que pueden acceder, cuándo o
cómo se comparte.
▪ Esto también significa que una filtración de datos puede exponer nuestra información de
acceso.
▪ En cambio, cuando estos servicios se conectan directamente a la API de un banco, nosotros
entramos en el sitio web de nuestro banco y damos nuestro "Consentimiento informado" a
los datos que se necesitan.
▪ Nosotros o nuestro banco siempre podemos revocar ese permiso más adelante en caso de
que se produzcan infracciones.

o DESBLOQUEAR UN NUEVO CRECIMIENTO CON HIRO: El uso de una API no consiste únicamente en
asegurar la automatización en el futuro.
▪ Se trata de abrir posibilidades totalmente nuevas para nuestro negocio.
▪ Según Paolo Malinverno, vicepresidente de investigación de Gartner, "Ya vivimos en una
economía de las APIs en la que los CEOs deben mirar más allá de las APIs como tecnología y,
en cambio, construir los modelos de negocio, las estrategias digitales y los ecosistemas de sus
empresas sobre ellas."
▪ Con la combinación de IA y automatización del conocimiento de HIRO, se obtiene una
solución potente y rentable que puede desbloquear un nuevo crecimiento transformador; Y
quién sabe a dónde nos llevará eso.

14
o Esto es una representación de la teoría de lo que debería ser automatizado, representada por la
pirámide, y la realidad de lo que se hace usualmente en la forma del cono de helado frutal.
o Como notarán, la automatización del Front End, alias la GUI o UI, es lo que menos foco debería tener;
Hay buenos motivos para esto:
▪ La interfaz generalmente no es muy estable en un ambiente de pruebas.
▪ Los locators cambian a menudo.
▪ El performance es disparejo.

o Lo que ven en el medio, los TESTS DE INTEGRATION, son lo que debería ser el verdadero foco de un
Automation Engineer.

15
CONCLUSIONES

▪ Una interfaz gráfica de usuario es muy visual por naturaleza.

➢ Como interfaz, está formada por las pantallas y los elementos interactivos por los que
te desplazas, tecleas o haces clic en programas de software, páginas web, sistemas
operativos y aplicaciones móviles.
➢ Por ejemplo, los controles deslizantes, los botones, los campos de texto y las listas
desplegables con los que se interactúa a diario forman parte de las GUI.

▪ En cambio, las API son una realidad digital invisible pero siempre presente.
▪ Con más de 22.000 de uso público, son interfaces de fondo que transfieren datos, como las
peticiones y respuestas de los usuarios, entre aplicaciones y servidores.
▪ Gracias a las API que obtienen y envían datos entre bastidores, nosotros podemos ver los
horarios de los vuelos directamente en Google o entrar en un sitio web sólo con nuestras
credenciales de Facebook o pagar con PayPal en una tienda online.
➢ Indispensables para los negocios digitales, las API "Se han convertido en un
importante motor de crecimiento empresarial. Como tejido conectivo que une
ecosistemas de tecnologías y organizaciones, las API permiten a las empresas
monetizar los datos, forjar asociaciones rentables y abrir nuevas vías de innovación y
crecimiento", según McKinsey.

▪ En pocas palabras, una interfaz gráfica de usuario para una página web mostraría
información enviada por una API junto con elementos interactivos, mientras que una API
conectaría y transferiría datos entre esa página web y un servidor entre bastidores.

▪ REGLA DE ORO: Si estamos probando una funcionalidad MEDIANTE la UI (Interfaz gráfica),

preguntémonos si lo podemos hacer mediante pruebas de API; Si estamos probando LA UI
debemos hacer pruebas de UI (Con Selenium, Java, etc.)

16
 ELEMENTOS QUE COMPONEN A UNA PETICIÓN O REQUEST

REQUEST

• Básicamente nos formula la pregunta: ¿Que necesitamos pedir?

• Es un pedido que le estamos haciendo a un servidor o a un EndPoint, y esto lo que hace es manifestar que
estamos esperando como respuesta.
• Es un pedido en un determinado formato y tipo que le hacemos a un EndPoint (Puede ser un directorio, un
servidor, un proxy), para que él sepa lo que le estamos pidiendo.

HEADERS/COOKIES

• Los encabezados representan los metadatos asociados con la solicitud y la respuesta de la API.
• En ellos podemos pasar información relacionada con la seguridad de una API; como Authorization Key, Users
sesión token, etc; También definimos el tipo de contenido de la API.
• En términos simples, estábamos enviando detalles adicionales a la API para procesar nuestra solicitud.
• Son los detalles como el tipo de archivo en que se mandan las APIs (json, XML, etc).
o Ejemplo: Detalles de autorización.

ENDPOINT

• Es una URI (Universal Resource Identifier)

• Es muy parecido a lo que es una URL.
• Es una BASE URL (Como por ejemplo www.google.com ) , con un RECURSO (Como por ejemplo /images), y
además puede tener un PARÁMETRO (Como por ejemplo /{id}), ósea que el EndPoint completo sería
(www.google.com/images/{id}).
• Es la dirección donde la API esta alojada en el servidor.
• Una estructura básica seria: Base URL/resourse/(Query/Path) Parameters

RESOURCES O RECURSOS

• Son la representación de las API o colecciones que pueden ser accesibles desde el servidor.
• Son las secciones que tiene el servidor para sus diferentes servicios.
• Es el lugar específico donde vamos a hacer el Request.
• Por ejemplo, Google.com es el servidor (Es el lugar donde todas las API están almacenadas, ósea que ese es
el Base URI), y las APIs serian:
o Google.com/maps
o Google.com/search
o Google.com/images
o Google.com/docs

17
PARAMETERS O PARÁMETROS

• En ellos, estamos pasando específicamente datos que la API necesita procesar.

PATH PARAMETERS

o Son partes de una ruta URL.

o También se conocen como RELATIVE URL.
o Por lo general, se usan para señalar un recurso específico dentro de una colección, como un usuario
identificado por ID.
o Básicamente se encuentran identificados con un / antes.
o Como:
▪ https://www.google.com/Images/1123343
▪ https://www.google.com/docs/1123343
▪ https://amazon.com/orders/112

QUERY PARAMETERS

o También llamado Parámetros de consulta.

o Son usados para ordenar o filtrar los recursos.
o Se encuentran identificados con ?
o Los parámetros de consulta se encuentran separados con &
o Como:
▪ https://amazon.com/orders?sort_by=2/20/2020

RESPONSE

• Es lo que recibimos luego de hacer un Request.

• Es la respuesta por parte del servidor o del EndPoint.
• Esto es lo que nos da pie para validar o testear cosas.

18
 SERVICIOS WEB

DEFINICIÓN

• Un web service o servicio web es un software con un formato basado en texto que funciona con Internet.
• Este sistema se encarga de permitir la transmisión de solicitudes y respuestas entre diferentes servidores o
aplicaciones, sin importar las diferencias que existan entre los lenguajes de programación en el que fueron
desarrolladas o la plataforma en la que se ejecutan.
• En otras palabras, un web service es, como su nombre lo indica, un servicio que hace posible la comunicación
de máquina a máquina y el intercambio de datos entre aplicaciones a través de una red de Internet.
o No se puede mencionar el término "Web services" hoy en día sin evocar inmediatamente referencias
como Amazon Web Services (AWS) o el servicio web de Google.
o Estos gigantes tecnológicos se han llevado el trofeo al abordar la necesidad de desarrollo de
aplicaciones. La escala de empresas como Amazon y Google es exactamente lo que hace posible los
servicios web modernos.

• Gracias a los web service es posible realizar una gran cantidad de interacciones cotidianas entre aplicaciones,
incluso sin que te des cuenta de ello.
o Por ejemplo, es necesario el uso de un web service al conectar la información de tu cuenta de
Facebook con un juego que recién descargaste, al igual que para utilizar la información de inicio de
sesión de Google, e incluso para abrir una nueva cuenta en otra aplicación sin rellenar el formulario.

• Es un método de comunicación entre 2 aplicaciones o equipos electrónicos sobre World Wide Web (WWW).
• Son una colección de operaciones, como: Buscar hoteles con un destino.
• Existen 2 tipos de servicios: SOAP y REST.

CARACTERÍSTICAS DE LOS SERVICIOS WEB

• Algunas de las características que distinguen a los web services son las siguientes:
o Permite la interoperabilidad y el uso de multiplataformas.
o Su formato está basado en texto.
o Es una herramienta de fácil uso y acceso.
o Provee servicios integrados.
o Su alcance es global.
o Hace posible el intercambio de mensajes SOAP (Simple Object Access Protocol).
o Interfaz descrita en WSDL (Web Service Description Language).
o Se apoya en el formato HTTP (Protocolo de transferencia de hipertexto).

¿CÓMO FUNCIONA UN SERVICIO WEB?

• El funcionamiento de un web service se da a través de las interacciones que se producen entre los
componentes de su arquitectura.
• La arquitectura de un web service estandarizado se basa en el uso de tres componentes principales:
o El proveedor del servicio web o service provider.
o El solicitante del servicio web o service requester.
o El corredor de servicios o service broker.

19
PROCESO DEL FUNCIONAMIENTO DE UN SERVICIO WEB

• En el aspecto técnico, lo primero que sucede para el funcionamiento de un web service es que el proveedor
de servicios envía un archivo WSDL con la definición del servicio web al corredor de servicios.
o Con este archivo, el corredor de servicios es capaz de saber qué funciones será posible ejecutar en el
servidor a través del web service.

• Después, el solicitante del servicio se comunica con el corredor de servicios para averiguar quién es el
proveedor.
o De esta forma, el solicitante puede comunicarse con el proveedor de servicios para enviar una
solicitud SOAP en forma de mensaje HTTP al servidor.

• Una vez que esto sucede, el web service interpreta el contenido de la solicitud y el proveedor de servicios
valida la petición del solicitante.

• Posteriormente, el web service envía los datos de respuesta necesarios en formato XML (extensible Markup
Language), usando nuevamente el protocolo SOAP y HTTP.

• Finalmente, el fichero XML, enviado por el proveedor de servicios, es validado una vez más por el solicitante
de los servicios, utilizando un fichero XSD (XML Schema Definition) para interpretarlo.
o La información resultante se envía al software y estará lista para ser procesada.

ESTRUCTURA DE UN SERVICIO WEB

• De manera resumida, un archivo WSDL contiene los siguientes elementos en su formato:

o ELEMENTO TYPE: Describe los tipos no estándar usados por los mensajes (Elemento Message).

o ELEMENTO MESSAGE: Define los datos que contienen los mensajes pasados de un punto a otro.

o ELEMENTO PORTTYPE: Establece una colección de operaciones brindadas por el servicio.

▪ Cada operación tiene un mensaje de entrada y uno de salida que se corresponde con algún
mensaje definido anteriormente.

o ELEMENTO BINDING: Describe los protocolos de servicio web que se utilizan para llevar a cabo la
comunicación en un determinado PortType.

o ELEMENTO PORT: Define una dirección (URL) para un determinado Binding.

o ELEMENTO SERVICE: Define una colección de Ports.

20
EJEMPLOS DE SERVICIOS WEB

AMAZON WEB SERVICES

o Amazon, una de las empresas de comercio electrónico más populares, tiene una interfaz de servicio
web que ofrece una serie de características interesantes.
o Las posibilidades van desde consultas simples de los catálogos de Amazon hasta sitios web de
ecommerce que operan en asociación con Amazon a través de su programa de afiliados.
o El mecanismo que utiliza Amazon para expandir sus actividades comerciales en línea se basa en
servicios web basados en la nube.
o Mediante el uso de esta tecnología, Amazon Web Services (AWS) brinda acceso a la infraestructura
técnica de Amazon. Básicamente, AWS se puede implementar utilizando los tipos de servicios web
SOAP o REST, pero la mayoría de las implementaciones de AWS siguen el enfoque REST.
o Como explica Eduardo Spotti, arquitecto DevOps y profesor del curso online de fundamentos de la
infraestructura Cloud Core Services, las soluciones cloud como AWS te brindan un panorama amplio
sobre la arquitectura de un servicio web en la nube y sobre el almacenamiento de objetos y su ciclo
de vida.
o Para comenzar a utilizar AWS, primero debes configurar una cuenta de desarrollador de AWS.
▪ Una vez registrado, recibirás un ID de suscripción, que se utilizará como clave para obtener
acceso a los web services gratuitos ofrecidos por Amazon, aunque algunos requieren
suscripciones pagas o implican tarifas de pago por uso.

GOOGLE

o Google proporciona una interfaz de servicio web basada en SOAP a su motor de búsqueda público
para acceder a sus recursos en un modelo de servicios web.
▪ De hecho, este web service se denomina API web de Google.

o La API de Google se puede utilizar para acceder mediante programación a varios servicios diferentes,
incluida la ejecución de una búsqueda en Google y la recepción de los resultados, la solicitud de una
sugerencia ortográfica y la obtención de una página almacenada en caché.
▪ Además, puedes utilizar su web service para consultar el motor de búsqueda de Google
desde una aplicación en lugar de un navegador, por lo que los resultados de la búsqueda se
registran como datos estructurados para que la aplicación solicitante pueda procesar la
información.

o Al igual que Amazon Web Services, para utilizar la API web de Google, debes crear una cuenta de
Google y recibir una clave que se transmite con cada solicitud.

21
T-MOBILE

o A veces, los servicios web pueden ayudar a habilitar un nuevo modelo comercial.
o T-Mobile International es uno de los principales proveedores internacionales de comunicaciones
móviles del mundo.
o Una de sus ofertas de servicios, T-Mobile Online, proporciona un portal web inalámbrico para más de
tres millones de clientes de T-Mobile en Austria, la República Checa, Alemania y el Reino Unido.
▪ Como ocurre con la mayoría de los planes inalámbricos, el modelo comercial se basa en el
uso del consumidor.

o T-Mobile se dio cuenta de que para promover el uso del consumidor necesitaba proporcionar
contenido interesante en el portal.
▪ Uno de los mayores desafíos que enfrentó T-Mobile fue encontrar una manera de dar a los
proveedores de contenido acceso a información sobre consumidores individuales.

o Por tal motivo, la contratación de web services fue fundamental para asegurarse de que fuera lo más
fácil posible para los proveedores de contenido unirse a la red.

22
VENTAJAS Y DESVENTAJAS DE UN WEB SERVICE

• Probablemente en este punto te sea muy fácil deducir cuáles son las ventajas y desventajas de un web
service.
o Pero, por si aún te quedan algunas dudas, a continuación, te dejaremos una lista de estas:

VENTAJAS

INTEROPERABILIDAD

▪ La capacidad de interoperabilidad es una característica de los web services que permite que
cualquiera de estos sea capaz de interactuar con otro web service sin importar el lenguaje en
el que esté implementado, gracias a lo cual los desarrolladores no tienen que preocuparse
por hacer ningún tipo de cambio en sus ambientes para hacer uso de un web service.

OMNIPRESENCIA

▪ El hecho de que los web service se comuniquen a través de formatos HTTP y XML, los hace
ser altamente flexibles y adaptables a distintos dispositivos capaces de trabajar con estas
tecnologías.
▪ Es por eso que los web services son usados e implementados en diferentes dispositivos
electrónicos y cada vez son más parte de nuestras vidas.

BAJA COMPLEJIDAD

▪ Debido a la forma en la que se estructura un web service y su funcionamiento, la complejidad

de su uso es reducida y, por ello, es también más accesible.
▪ Incluso, existen herramientas que hacen que su creación sea aún más rápida y fácil.

SOPORTE

▪ La gran mayoría de las empresas de software soportan el protocolo SOAP, con el que
funcionan la mayoría de los servicios web, por lo que es muy conveniente utilizar este
sistema.

23
DESVENTAJAS

SEGURIDAD

▪ En algunas ocasiones los web service son publicados sin ningún tipo de restricción de
seguridad, lo cual puede hacer que sean poco fiables cuando los datos que se van a
intercambiar entre aplicaciones son sensibles.

TRANSACCIONES

▪ Aunque es posible realizar transacciones mediante un web service, existen otros tipos de
software que están mucho más desarrollados para tales acciones que un web service y que se
especializan en este tipo de operaciones.

EFICACIA

▪ Uno de los inconvenientes derivados de que los web services funcionen con un formato
basado en texto es que el rendimiento de estos es bajo en comparación con otros modelos
de computación distribuida, tales como Java Remote Method Invocation (RMI), CORBA o
Distributed Component Object Model (DCOM).
▪ Esto debido a que entre los objetivos de XML no se encuentra la concisión ni la eficacia de
procesamiento.

VELOCIDAD

▪ A pesar de todos sus avances tecnológicos, las pruebas y los procesos de servicios web siguen
siendo un poco lentos.
▪ Dado que dependen de los sistemas operativos para administrar las aplicaciones, las
variaciones más pequeñas pueden resultar en flujos de trabajo multifacéticos al intentar
mover datos entre los servidores y la nube, lo que puede afectar su ecosistema y su
estrategia de integración de aplicaciones.

24
API REST

• La sigla REST es el acrónimo de Representational State Transfer.

• Es un estilo de arquitectura para el desarrollo de aplicaciones, en donde el mecanismo de comunicación entre
sistemas se establece a través de peticiones HTTP.
• Para el intercambio de información se puede usar XML, JSON, texto plano, entre otros tipos de datos.
• Es una arquitectura que utiliza el protocolo HTTP para el intercambio de datos.
• Expone los métodos a través de URIs.
• REST permite el intercambio de datos en formato JSON, XML, texto plano, entre otros.
• Es una arquitectura.
o ARQUITECTURA DE SOFTWARE: Es la forma en que está diseñado un sistema, como están
organizados sus componentes, como se comunican entre ellos, que funciones cumplen, etc.
▪ Es decir, si yo quiero que mi aplicación pueda consumirse desde otras Apps, yo puedo definir
los permisos.

• La Transferencia de Estado Representacional (En inglés Representational State Transfer) o REST es un estilo
de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web.
• El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los
principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la
comunidad de desarrollo.
• Si bien el término REST se refería originalmente a un conjunto de principios de arquitectura, en la actualidad
se usa en el sentido más amplio para describir cualquier interfaz entre sistemas que utilice directamente
HTTP para obtener datos o indicar la ejecución de operaciones sobre los datos, en cualquier formato (XML,
JSON, etc.) sin las abstracciones adicionales de los protocolos basados en patrones de intercambio de
mensajes, como por ejemplo SOAP.
• Es posible diseñar sistemas de servicios web de acuerdo con el estilo arquitectural REST de Fielding y también
es posible diseñar interfaces XMLHTTP de acuerdo con el estilo de llamada a procedimiento remoto (RPC),
pero sin usar SOAP.
• Estos dos usos diferentes del término REST causan cierta confusión en las discusiones técnicas, aunque RPC
no es un ejemplo de REST.
• REST afirma que la web ha disfrutado de escalabilidad como resultado de una serie de diseños fundamentales
clave:

o UN PROTOCOLO CLIENTE/SERVIDOR SIN ESTADO: Cada mensaje HTTP contiene toda la información
necesaria para comprender la petición.
▪ Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las
comunicaciones entre mensajes.
▪ Sin embargo, en la práctica, muchas aplicaciones basadas en HTTP utilizan cookies y otros
mecanismos para mantener el estado de la sesión (Algunas de estas prácticas, como la
reescritura de URLs, no son permitidas por REST).

o UN CONJUNTO DE OPERACIONES BIEN DEFINIDAS QUE SE APLICAN A TODOS LOS RECURSOS DE

INFORMACIÓN: HTTP en sí define un conjunto pequeño de operaciones, las más importantes son
POST, GET, PUT y DELETE.
▪ Con frecuencia estas operaciones se equiparán a las operaciones CRUD en bases de datos
(CLAB en castellano: Crear, Leer, Actualizar, Borrar) que se requieren para la persistencia de
datos, aunque POST no encaja exactamente en este esquema.

o UNA SINTAXIS UNIVERSAL PARA IDENTIFICAR LOS RECURSOS: En un sistema REST, cada recurso es
direccionable únicamente a través de su URL.
25
 o EL USO DE HIPERMEDIOS: Tanto para la información de la aplicación como para las transiciones de
estado de la aplicación: la representación de este estado en un sistema REST son típicamente HTML o
XML.
▪ Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente
siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional.

¿QUE DEBO SABER AL DESARROLLAR UNA API REST?

o En primer lugar, cada recurso (Información) que yo consulto tiene un identificador único llamado URI,
y se consulta por algo llamado EndPoint (La URL completa).
▪ Esa URI permite consultar directamente un recurso, por ejemplo: edteam/juan/usuario
▪ Es un identificador único, y de esa manera se puede encontrar cualquier recurso que se
necesite o una lista de ellos.

o Cuando se solicita una información a través de una API el servidor puede contestar con distintos
códigos, con esos códigos vamos a saber que paso con mi petición.

▪ CÓDIGOS 2XX: Indican que todo fue exitoso, indica respuesta exitosa.
▪ CÓDIGOS 3XX: Indican redirecciones.
▪ CÓDIGOS 4XX: Indican que se ha hecho una solicitud invalida.
▪ CÓDIGOS 5XX: Indican errores directamente en el servidor.

26
SOAP

• La sigla SOAP significa Simple Object Access Protocol.

• Principalmente es un protocolo para el diseño y construcción de servicios web usando la tecnología XML, lo
que permite establecer comunicación entre sistemas.
• Dado que está basado en XML, el protocolo SOAP es independiente de lenguaje y plataforma.
• Es un protocolo para el intercambio de datos.
• Usa el WSDL para exponer los métodos y detalles técnicos.
• Los servicios web y sus clientes usan el WSDL como contrato.
• Los servicios web de este tipo están altamente acoplados con el cliente, debido a la existencia de un contrato.
• Es un protocolo para mandar y recibir mensajes entre aplicaciones sin enfrentarse al problema de la
interoperabilidad.

WSDL

o Es un documento XML que describe el servicio web.

o Es el contrato del servicio web.
o Especifica la localización y los métodos del servicio usando más que todo los siguientes elementos:
Los tipos de datos que se utilizan en los elementos de datos del servicio web para cada operación
describen las operaciones que se pueden realizar y el mensaje que conlleva.

DIFERENCIAS ENTRE SOAP Y WSDL

o Un mensaje SOAP es un documento XML que es usado para transmitir nuestros datos.
o WSDL es un documento XML que describe como conectar y hacer peticiones al servicio web.
o Básicamente los mensajes SOAP son datos que nosotros transmitimos; y WSDL nos dice que podemos
hacer y cómo podemos hacer esas peticiones.
o SOAP es la estructura que se aplica a los mensajes/datos para su transferencia.
o WSDL es usado solo para determinar cómo hacer peticiones al servicio en primer lugar.

27
DIFERENCIAS SOAP Y REST

• Una de las principales diferencias entre estos tipos de web service o servicios web es el protocolo o formato
que utilizan para intercambiar datos entre aplicaciones, el protocolo SOAP o el protocolo REST.
• Hasta ahora, los web service que funcionan con SOAP son los más comunes.
o Por otro lado, los web service que utilizan el protocolo REST tienen un funcionamiento prácticamente
igual a los del protocolo SOAP.

• Sin embargo, los web service de tipo RESTful tienen algunas diferencias, ya que a comparación del protocolo
SOAP, el protocolo REST no está estructurado bajo estándares definidos y es más ligero.
o Además, es mucho más flexible y permite que funcione no solo con lenguaje XML, sino también con
JSON (JavaScript Object Notation), entre otros.

SOAP

o SOAP soporta únicamente información en formato XML.

o Se considera que la curva de aprendizaje es dura, dado que requiere conocimiento para la generación
del WSDL y los clientes del servicio.
o Es complicado mantener este tipo de servicios, dado que un cambio en el WSDL requiere la
modificación del cliente.

REST

o No existen contratos entre el servidor y el cliente.

o Los servicios web de este tipo presentan bajo acoplamiento.
o Es considerado fácil de aprender, dado que se trabaja con simples métodos HTTP.
o Son fáciles de mantener, debido a que, al agregar un nuevo método, no es necesario hacer cambios
en los clientes del servicio web.

28
 AUTENTICACIÓN

DEFINICIÓN

• Es la manera de acceder a las APIs.

BASIC AUTH

• Es una autenticación básica donde los responsables de un software guardan el usuario y la contraseña en la
misma página o software.
• Es una autenticación que nos pide:
o Username: j66cam
o Password: micontraseña123

BEARER MEDIANTE TOKEN

• Pide una autenticación por Token (Una cadena muy larga de caracteres alfanumeros).
• En autorización seleccionamos en el tipo: Bearer Token
o Token: 1234567890asdfghjklñqwertyuiiopzcxvbnbmjdhgsfu

OAUTH

• Es cuando podemos logearnos en una aplicación por medio de un servicio externo como ingresar a la app por
medio de Facebook o Gmail.
o Donde no se guardan el usuario y la contraseña en la página o software.

• Está basada en 2 claves, la clave del consumidor y la clave secreta.

• En autorización seleccionamos en el tipo: OAuth 1.0
• La clave del consumidor siempre es la misma, pero la clave secreta va cifrando claves validas basándose en la
clave del consumidor.
• A partir de la clave del consumidor va generando claves que coinciden o pueden coincidir con esa clave del
consumidor, y el otro extremo hace la desencriptación, y tiene que coincidir, que esa nueva clave coincide
con ese consumidor.
o Consumer Key: RKCGzna7bv9YD57c
o Consumer Secret: D+EdQ-gs$-%@2Nu7

HAWK AUNTHETICATION

• La autenticación Hawk es un protocolo ampliamente utilizado para proteger los puntos finales de la API.
• Uno de los principales objetivos de Hawk es permitir la autenticación HTTP para los servicios que no utilizan
TLS (aunque también se puede utilizar junto con TLS).
o Hawk Auth ID: dh37fgj492je
o Hawk Auth Key: werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn
o Algorithm: sha256

29
 MÉTODOS HTTP

DEFINICIÓN

• HTTP define un conjunto de métodos de petición para indicar la acción que se desea realizar para un recurso
determinado.
• Aunque estos también pueden ser sustantivos, estos métodos de solicitud a veces son llamados HTTP verbs.
• Cada uno de ellos implementan una semántica diferente, pero algunas características similares son
compartidas por un grupo de ellos: ej. un request method puede ser safe, idempotent (en-US), o cacheable.
• Estos métodos permiten interactuar con la API.
• Es equivalente al CRUD de las bases de datos (Create-Post, Read-Get, Update-Put, Delete-Delete)

GET

• Sirve para solicitar información.

POST

• Sirve para enviar nueva información.

• Sirve para la inserción de datos.
• Como la creación de un nuevo usuario en una página.
• Nunca se aconseja que se haga un servicio tipo post enviando los datos a la cabecera (URL), porque la
información viajara de manera no segura. podría ser capturada.
• La información debe viajar en el cuerpo (Body).

PUT

• Sirve para actualizar información que ya exista.

• Se utiliza cuando se quiere actualizar un registro en la base de datos.
• El problema con PUT, es que debemos poner el valor de todos los parámetros que tenga la petición, o dejara
nulos los valores de los parámetros que no pongamos.

PATCH

• Es similar al PUT, pero solo actualiza el valor del parámetro especifico que pongamos.

DELETE

• Sirve para borrar un recurso.

30
HEAD

• Similar a GET, pero no se obtiene el cuerpo de respuesta, únicamente los metadatos de la cabecera.
• Obtiene sólo los datos del Header de la aplicación, no del body.

OPTIONS

• Devuelve los métodos HTTP soportados por el servidor para la URL especificada.
• Ósea, que métodos HTTP sirven con la API (Como GET, Head, POST, etc.)

TRACE

• Este método realiza un bucle de retorno de mensajes, lo que significa que devolverá el contenido del mensaje
como Respuesta, proporcionando un útil mecanismo de depuración.
• Devolverá la misma información que se ha enviado en la solicitud; Es una especie de eco.
• Sirve para comprobar si la solicitud se ha visto modificada por servidores intermedios.

IDEMPOTENCIA

• Significa que al ejecutar los métodos una y otra vez, SIEMPRE vamos a obtener el mismo resultado.

31
 CÓDIGOS DE ESTADO HTTP

DEFINICIÓN

• Los códigos de estado de respuesta HTTP indican si se ha completado satisfactoriamente una solicitud HTTP
específica.
• Las respuestas se agrupan en cinco clases:
o Respuestas informativas (100–199),
o Respuestas satisfactorias (200–299),
o Redirecciones (300–399),
o Errores de los clientes (400–499),
o y errores de los servidores (500–599).

• Estas frases están destinadas a dar una descripción intuitiva del estatus.
• El primer dígito del código de respuesta específica una de las cinco clases de respuesta.
• Cuando se solicita una información a través de una API el servidor puede contestar con distintos códigos, con
esos códigos vamos a saber que paso con mi petición.

o CÓDIGOS 1XX: Indican respuestas informativas.

o CÓDIGOS 2XX: Indican que todo fue exitoso, indica respuesta exitosa.
o CÓDIGOS 3XX: Indican redirecciones.
o CÓDIGOS 4XX: Indican que se ha hecho una solicitud invalida.
o CÓDIGOS 5XX: Indican errores directamente en el servidor.

32
1XX RESPUESTAS INFORMATIVAS

• Petición recibida, continuando proceso.

• Esta respuesta significa que el servidor ha recibido los encabezados de la petición, y que el cliente debería
proceder a enviar el cuerpo de la misma (En el caso de peticiones para las cuales el cuerpo necesita ser
enviado; por ejemplo, una petición Hypertext Transfer Protocol).
• Si el cuerpo de la petición es largo, es ineficiente enviarlo a un servidor, cuando la petición ha sido ya
rechazada, debido a encabezados inapropiados.
• Para hacer que un servidor chequee si la petición podría ser aceptada basada únicamente en los encabezados
de la petición, el cliente debe enviar Expect: 100-continue como un encabezado en su petición inicial y
verificar si un código de estado 100 Continue es recibido en respuesta, antes de continuar (o recibir 417
Expectation Failed y no continuar).

100 CONTINUE

o Esta respuesta provisional indica que todo hasta ahora está bien y que el cliente debe continuar con
la solicitud o ignorarla si ya está terminada.

101 SWITCHING PROTOCOL

o Este código se envía en respuesta a un encabezado de solicitud Upgrade (en-US) por el cliente e
indica que el servidor acepta el cambio de protocolo propuesto por el agente de usuario.

102 PROCESSING (WEBDAV)

o Este código indica que el servidor ha recibido la solicitud y aún se encuentra procesándola, por lo que
no hay respuesta disponible.

103 EARLY HINTS (EN-US)

o Este código de estado está pensado principalmente para ser usado con el encabezado Link,
permitiendo que el agente de usuario empiece a precargar recursos mientras el servidor prepara una
respuesta.

33
2XX PETICIONES CORRECTAS (TODO SALIÓ BIEN)

• Esta clase de código de estado indica que la petición fue recibida correctamente, entendida y aceptada.
• En la comunidad de TI, "ok2xx" significa la finalización exitosa de cualquier tarea y la preparación para otras
nuevas, que se ha desarrollado por analogía con la clase de códigos de éxito 2xx.
• GET: El recurso se ha obtenido y se transmite en el cuerpo del mensaje.
• HEAD: Los encabezados de entidad están en el cuerpo del mensaje.
• PUT o POST: El recurso que describe el resultado de la acción se transmite en el cuerpo del mensaje.
• TRACE: El cuerpo del mensaje contiene el mensaje de solicitud recibido por el servidor.

200 OK (CÓDIGO COMÚN)

o La solicitud ha tenido éxito.

o El significado de un éxito varía dependiendo del método HTTP.

201 CREATED

o La solicitud ha tenido éxito y se ha creado un nuevo recurso como resultado de ello.

o Ésta es típicamente la respuesta enviada después de una petición PUT.

202 ACCEPTED

o La solicitud se ha recibido, pero aún no se ha actuado.

o Es una petición "sin compromiso", lo que significa que no hay manera en HTTP que permite enviar
una respuesta asíncrona que indique el resultado del procesamiento de la solicitud.
o Está pensado para los casos en que otro proceso o servidor maneja la solicitud, o para el
procesamiento por lotes.

203 NON-AUTHORITATIVE INFORMATION

o La petición se ha completado con éxito, pero su contenido no se ha obtenido de la fuente

originalmente solicitada, sino que se recoge de una copia local o de un tercero.
o Excepto esta condición, se debe preferir una respuesta de 200 OK en lugar de esta respuesta.

204 NO CONTENT (EN-US)

o La petición se ha completado con éxito, pero su respuesta no tiene ningún contenido, aunque los
encabezados pueden ser útiles.
o El agente de usuario puede actualizar sus encabezados en caché para este recurso con los nuevos
valores.

205 RESET CONTENT (EN-US)

o La petición se ha completado con éxito, pero su respuesta no tiene contenidos y, además, el agente
de usuario tiene que inicializar la página desde la que se realizó la petición, este código es útil por
ejemplo para páginas con formularios cuyo contenido debe borrarse después de que el usuario lo
envíe.

34
206 PARTIAL CONTENT

o La petición servirá parcialmente el contenido solicitado.

o Esta característica es utilizada por herramientas de descarga como wget para continuar la
transferencia de descargas anteriormente interrumpidas, o para dividir una descarga y procesar las
partes simultáneamente.

207 MULTI-STATUS (WEBDAV)

o Una respuesta Multi-Estado transmite información sobre varios recursos en situaciones en las que
varios códigos de estado podrían ser apropiados.
o El cuerpo de la petición es un mensaje XML.

208 MULTI-STATUS (WEBDAV)

o El listado de elementos DAV ya se notificó previamente, por lo que no se van a volver a listar.

226 IM USED (HTTP DELTA ENCODING)

o El servidor ha cumplido una petición GET para el recurso y la respuesta es una representación del
resultado de una o más manipulaciones de instancia aplicadas a la instancia actual.

35
3XX REDIRECCIONES (CUANDO SE CARGA OTRO RECURSO)

• El cliente tiene que tomar una acción adicional para completar la petición.
• Esta clase de código de estado indica que una acción subsecuente necesita efectuarse por el agente de
usuario para completar la petición.
• La acción requerida puede ser llevada a cabo por el agente de usuario sin interacción con el usuario si y solo
si el método utilizado en la segunda petición es GET o HEAD.
• El agente de usuario no debe redirigir automáticamente una petición más de 5 veces, dado que tal
funcionamiento indica usualmente un Bucle infinito.

300 MULTIPLE CHOICE (EN-US)

o Esta solicitud tiene más de una posible respuesta.

o User-Agent o el usuario debe escoger uno de ellos.
o No hay forma estandarizada de seleccionar una de las respuestas.

301 MOVED PERMANENTLY (CÓDIGO COMÚN)

o Este código de respuesta significa que la URL del recurso solicitado ha sido cambiado.
o Probablemente una nueva URL sea devuelta en la respuesta.

302 FOUND

o Este código de respuesta significa que el recurso de la URL solicitada ha sido cambiado
temporalmente.
o Nuevos cambios en la URL serán agregados en el futuro.
o Por lo tanto, la misma URL debe ser usada por el cliente en futuras solicitudes.

303 SEE OTHER (EN-US) (CÓDIGO COMÚN)

o El servidor envía esta respuesta para dirigir al cliente a un nuevo recurso solicitado a otra dirección
usando una petición GET.

304 NOT MODIFIED

o Esta es usada para propósitos de "caché".

o Le indica al cliente que la respuesta no ha sido modificada.
o Entonces, el cliente puede continuar usando la misma versión almacenada en su caché.

305 USE PROXY

o Fue definida en una versión previa de la especificación del protocolo HTTP para indicar que una
respuesta solicitada debe ser accedida desde un proxy.
o Ha quedado obsoleta debido a preocupaciones de seguridad correspondientes a la configuración de
un proxy.

36
306 UNUSED

o Este código de respuesta ya no es usado más.

o Actualmente se encuentra reservado.
o Fue usado en previas versiones de la especificación HTTP1.1.

307 TEMPORARY REDIRECT (EN-US)

o El servidor envía esta respuesta para dirigir al cliente a obtener el recurso solicitado a otra URL con el
mismo método que se usó la petición anterior.
o Tiene la misma semántica que el código de respuesta HTTP 302 Found, con la excepción de que el
agente usuario no debe cambiar el método HTTP usado: si un POST fue usado en la primera petición,
otro POST debe ser usado en la segunda petición.

308 PERMANENT REDIRECT (EN-US)

o Significa que el recurso ahora se encuentra permanentemente en otra URL, especificada por la
respuesta de encabezado HTTP Location:
o Tiene la misma semántica que el código de respuesta HTTP 301 Moved Permanently, con la
excepción de que el agente usuario no debe cambiar el método HTTP usado: si un POST fue usado en
la primera petición, otro POST debe ser usado en la segunda petición.

37
4XX ERRORES DEL CLIENTE (ÓSEA DE NOSOTROS)

• La solicitud contiene sintaxis incorrecta o no puede procesarse.

• La intención de la clase de códigos de respuesta 4XX es para casos en los cuales el cliente parece haber
errado la petición.
• Excepto cuando se responde a una petición HEAD, el servidor debe incluir una entidad que contenga una
explicación a la situación de error, y si es una condición temporal o permanente.
• Estos códigos de estado son aplicables a cualquier método de solicitud (como GET o POST).
• Los agentes de usuario deben desplegar cualquier entidad al usuario.
• Estos son típicamente los códigos de respuesta de error más comúnmente encontrados.

400 BAD REQUEST (CÓDIGO COMÚN)

o Esta respuesta significa que el servidor no pudo interpretar la solicitud dada una sintaxis inválida.

401 UNAUTHORIZED (CÓDIGO COMÚN)

o Es necesario autenticar para obtener la respuesta solicitada.

o Esta es similar a 403, pero en este caso, la autenticación es posible.

402 PAYMENT REQUIRED

o Este código de respuesta está reservado para futuros usos.

o El objetivo inicial de crear este código fue para ser utilizado en sistemas digitales de pagos.
o Sin embargo, no está siendo usado actualmente.

403 FORBIDDEN (CÓDIGO COMÚN)

o El cliente no posee los permisos necesarios para cierto contenido, por lo que el servidor está
rechazando otorgar una respuesta apropiada.

404 NOT FOUND (CÓDIGO COMÚN)

o El servidor no pudo encontrar el contenido solicitado.

o Este código de respuesta es uno de los más famosos dada su alta ocurrencia en la web.

405 METHOD NOT ALLOWED (EN-US) (CÓDIGO COMÚN)

o El método solicitado es conocido por el servidor, pero ha sido deshabilitado y no puede ser utilizado.
o Los dos métodos obligatorios, GET y HEAD, nunca deben ser deshabilitados y no deberían retornar
este código de error.

406 NOT ACCEPTABLE (EN-US)

o Esta respuesta es enviada cuando el servidor, después de aplicar una negociación de contenido
servidor-impulsado, no encuentra ningún contenido seguido por la criteria dada por el usuario.

38
407 PROXY AUTHENTICATION REQUIRED (EN-US) (CÓDIGO COMÚN)

o Esto es similar al código 401, pero la autenticación debe estar hecha a partir de un proxy.

408 REQUEST TIMEOUT (CÓDIGO COMÚN)

o Esta respuesta es enviada en una conexión inactiva en algunos servidores, incluso sin alguna petición
previa por el cliente.
o Significa que el servidor quiere desconectar esta conexión sin usar.
o Esta respuesta es muy usada desde algunos navegadores, como Chrome, Firefox 27+, o IE9, usa
mecanismos de pre-conexión HTTP para acelerar la navegación.
o También hay que tener en cuenta que algunos servidores simplemente desconectan la conexión sin
enviar este mensaje.

409 CONFLICT (EN-US)

o Esta respuesta puede ser enviada cuando una petición tiene conflicto con el estado actual del
servidor.

410 GONE (EN-US)

o Esta respuesta puede ser enviada cuando el contenido solicitado ha sido borrado del servidor.

411 LENGTH REQUIRED (EN-US)

o El servidor rechaza la petición porque el campo de encabezado Content-Length no está definido y el

servidor lo requiere.

412 PRECONDITION FAILED (EN-US)

o El cliente ha indicado precondiciones en sus encabezados la cual el servidor no cumple.

413 PAYLOAD TOO LARGE

o La entidad de petición es más larga que los límites definidos por el servidor; el servidor puede cerrar
la conexión o retornar un campo de encabezado Retry-After.

414 URI TOO LONG (EN-US)

o La URL solicitada por el cliente es más larga de lo que el servidor está dispuesto a interpretar.

415 UNSUPPORTED MEDIA TYPE (EN-US)

o El formato multimedia de los datos solicitados no está soportado por el servidor, por lo cual el
servidor rechaza la solicitud.

39
416 REQUESTED RANGE NOT SATISFIABLE (EN-US)

o El rango especificado por el campo de encabezado Range en la solicitud no cumple; es posible que el
rango está fuera del tamaño de los datos objetivo del URL.

417 EXPECTATION FAILED (EN-US)

o Significa que la expectativa indicada por el campo de encabezado Expect solicitada no puede ser
cumplida por el servidor.

418 I'M A TEAPOT

o El servidor se rehúsa a intentar hacer café con una tetera.

o "Soy una tetera".
o Este código fue definido en 1998 como una inocentada, en el Protocolo de Transmisión de Hipertexto
de Cafeteras (RFC-2324).
o No se espera que los servidores web implementen realmente este código de error, pero es posible
encontrar sitios que devuelvan este código HTTP.

421 MISDIRECTED REQUEST

o La petición fue dirigida a un servidor que no es capaz de producir una respuesta.

o Esto puede ser enviado por un servidor que no está configurado para producir respuestas por la
combinación del esquema y la autoridad que están incluidos en la URI solicitada

422 UNPROCESSABLE ENTITY (EN-US) (WEBDAV)

o La petición estaba bien formada pero no se pudo seguir debido a errores de semántica.

423 LOCKED (WEBDAV)

o El recurso que está siendo accedido está bloqueado.

424 FAILED DEPENDENCY (WEBDAV)

o La petición falló debido a una falla de una petición previa.

426 UPGRADE REQUIRED (EN-US)

o El servidor se rehúsa a aplicar la solicitud usando el protocolo actual, pero puede estar dispuesto a
hacerlo después que el cliente se actualice a un protocolo diferente.
o El servidor envía un encabezado Upgrade en una respuesta para indicar los protocolos requeridos.

428 PRECONDITION REQUIRED (EN-US)

o El servidor origen requiere que la solicitud sea condicional.

o Tiene la intención de prevenir problemas de 'actualización perdida', donde un cliente OBTIENE un
estado del recurso, lo modifica, y lo PONE devuelta al servidor, cuando mientras un tercero ha
modificado el estado del servidor, llevando a un conflicto.

40
429 TOO MANY REQUESTS (EN-US)

o El usuario ha enviado demasiadas solicitudes en un periodo de tiempo dado.

431 REQUEST HEADER FIELDS TOO LARGE (EN-US)

o El servidor no está dispuesto a procesar la solicitud porque los campos de encabezado son demasiado
largos.
o La solicitud PUEDE volver a subirse después de reducir el tamaño de los campos de encabezado
solicitados.

451 UNAVAILABLE FOR LEGAL REASONS (EN-US)

o El usuario solicita un recurso ilegal, como alguna página web censurada por algún gobierno.

41
5XX ERRORES DEL SERVIDOR

• El servidor falló al completar una solicitud aparentemente válida.

• Los códigos de respuesta que comienzan con el dígito "5" indican casos en los cuales el servidor tiene
registrado aún antes de servir la solicitud, que está errado o es incapaz de ejecutar la petición.
• Excepto cuando está respondiendo a un método HEAD, el servidor debe incluir una entidad que contenga
una explicación de la situación de error, y si es una condición temporal o permanente.
• Los agentes de usuario deben desplegar cualquier entidad incluida al usuario.
• Estos códigos de respuesta son aplicables a cualquier método de petición.

500 INTERNAL SERVER ERROR (CÓDIGO COMÚN)

o El servidor ha encontrado una situación que no sabe cómo manejarla.

501 NOT IMPLEMENTED (EN-US)

o El método solicitado no está soportado por el servidor y no puede ser manejado.

o Los únicos métodos que los servidores requieren soporte (Y por lo tanto no deben retornar este
código) son GET y HEAD.

502 BAD GATEWAY (CÓDIGO COMÚN)

o Esta respuesta de error significa que el servidor, mientras trabaja como una puerta de enlace para
obtener una respuesta necesaria para manejar la petición, obtuvo una respuesta inválida.

503 SERVICE UNAVAILABLE (CÓDIGO COMÚN)

o El servidor no está listo para manejar la petición.

o Causas comunes puede ser que el servidor está caído por mantenimiento o está sobrecargado.
o Hay que tomar en cuenta que, junto con esta respuesta, una página usuario-amigable explicando el
problema debe ser enviada.
o Estas respuestas deben ser usadas para condiciones temporales y el encabezado HTTP Retry-After:
debería, si es posible, contener el tiempo estimado antes de la recuperación del servicio.
o El webmaster debe también cuidar los encabezados relacionados al caché que son enviados junto a
esta respuesta, ya que estas respuestas de condición temporal deben usualmente no estar en el
caché.

504 GATEWAY TIMEOUT

o Esta respuesta de error es dada cuando el servidor está actuando como una puerta de enlace y no
puede obtener una respuesta a tiempo.

505 HTTP VERSION NOT SUPPORTED

o La versión de HTTP usada en la petición no está soportada por el servidor.

42
506 VARIANT ALSO NEGOTIATES (EN-US)

o El servidor tiene un error de configuración interna: negociación de contenido transparente para la

petición resulta en una referencia circular.

507 INSUFFICIENT STORAGE (EN-US)

o El servidor tiene un error de configuración interna: la variable de recurso escogida está configurada
para acoplar la negociación de contenido transparente misma, y no es por lo tanto un punto final
adecuado para el proceso de negociación.

508 LOOP DETECTED (EN-US) (WEBDAV)

o El servidor detectó un ciclo infinito mientras procesaba la solicitud.

510 NOT EXTENDED (EN-US)

o Extensiones adicionales para la solicitud son requeridas para que el servidor las cumpla.

511 NETWORK AUTHENTICATION REQUIRED (EN-US)

o El código de estado 511 indica que el cliente necesita autenticar para ganar acceso a la red.

43
 JSON

DEFINICIÓN

• Anteriormente la única manera de compartir información entre aplicaciones era mediante archivos XML.
• (JavaScript Object Notation): Es un pseudo lenguaje que sirve con varios lenguajes.
• Es un archivo donde creamos todas las listas de datos y objetos que vamos a usar en nuestro código son
archivos de información de elementos.
• Es un formato ligero de intercambio de datos.
• Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y
generarlo.
• JSON es un formato de texto que es completamente independiente del lenguaje, pero utiliza convenciones
que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#,
Java, JavaScript, Perl, Python, y muchos otros.
• Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos.
• JSON está constituido por dos estructuras:
o Una colección de pares de nombre/valor.
▪ En varios lenguajes esto es conocido como un objeto, registro, estructura, diccionario, tabla
hash, lista de claves o un arreglo asociativo.
o Una lista ordenada de valores.
▪ En la mayoría de los lenguajes, esto se implementa como arreglos, vectores, listas o
secuencias.
• Estas son estructuras universales; virtualmente todos los lenguajes de programación las soportan de una
forma u otra.
• Es razonable que un formato de intercambio de datos que es independiente del lenguaje de programación se
base en estas estructuras.
• Los string de las propiedades deben ir en comillas dobles (“”).

44
DATOS DE JSON

OBJETO

o Es un conjunto desordenado de pares nombre/valor.

o Un objeto comienza con {llave de apertura y termine con} llave de cierre.
o Cada nombre es seguido por : dos puntos y los pares nombre/valor están separados por coma (,).

NÚMERO

o Es similar a un número C o Java, excepto que no se usan los formatos octales y hexadecimales.

45
VALOR

o Puede ser una cadena de caracteres con comillas dobles, o un número, o true o false o null, o un
objeto o un arreglo.
o Estas estructuras pueden anidarse.

LOS ESPACIOS EN BLANCO

o Pueden insertarse entre cualquier par de símbolos.

o Exceptuando pequeños detalles de encoding, esto describe completamente el lenguaje.

46
ARREGLO

o Es una colección de valores.

o Un arreglo comienza con [corchete izquierdo y termina con] corchete derecho.
o Los valores se separan por coma (,).

CADENA DE CARACTERES

o Es una colección de cero o más caracteres Unicode, encerrados entre comillas dobles, usando barras
divisorias invertidas como escape.
o Un carácter está representado por una cadena de caracteres de un único carácter.
o Una cadena de caracteres es parecida a una cadena de caracteres C o Java.

47
FORMATO

• Debe asegurarse que las cadenas de texto vallan entre “ ” así usemos variables dinámicas, y los valores
numéricos no tienen necesidad de esto.

ARREGLOS DE DATOS

48
VARIABLES DINÁMICAS

49
JASON PATH

• Es la dirección de uno o varios parámetros del archivo Json.

• Es la manera en la que llegamos a los datos que necesitamos.
• Una buena herramienta para practicar y verificar el Json Path en nuestro archivo Json es:
o https://jsonpath.com/

50
ACCEDER AL VALOR DE UN PARÁMETRO PRINCIPAL

o $.nombreParametro

ACCEDER AL VALOR DE UN ARREGLO

o $.nombreParametro[indexValor]

51
ACCEDER AL VALOR DEL PARÁMETRO DE UN OBJETO

o $.nombreObjeto.parametroDelObjeto

52
 PROXY

DEFINICIÓN

• Los servidores proxy generalmente se usan como un puente entre el origen y el destino de una solicitud.
• En la imagen, se puede ver que la computadora necesita pasar por el servidor proxy para acceder a Internet,
y este es uno de los usos comunes de los servidores proxy.

• Un Proxy es una herramienta y, como todas las herramientas, puede usarse tanto para el bien como para el
mal.
• Los cibercriminales a menudo usan servidores proxy para cometer delitos, ya que conectan las máquinas que
atacarán a las personas con servicios de proxy que se encuentran en Internet, como proxies gratuitos o
incluso la red Tor, y llevan adelante sus ataques.
o Eso hace que las víctimas a las que ellos están atacando no puedan identificar el verdadero origen del
ataque, haciendo que las reglas de bloqueo no se pueden crear adecuadamente para evitar la
continuidad del ataque.

• Utilizar de forma adecuada y consciente las herramientas y los recursos que nos son ofrecidos nos brinda la
posibilidad de armar nuestro arsenal de seguridad, pero también es importante recordar que la mayoría de
las herramientas se pueden usar para una variedad de propósitos, por lo que saber cuáles son sus puntos
negativos puede ser de ayuda para configurarlas y usarlas de una manera bien estructurada.

• Tomemos el ejemplo de una empresa ficticia llamada ACME S.A.

o En ACME hay un servidor que permite navegar por Internet, un servidor proxy, y sin él no es posible
navegar en absoluto.
o Por lo tanto, todas las computadoras en la red deben tener la dirección proxy y el puerto de su
navegador configurados para que tenga lugar el acceso a Internet.

• CACHÉ: Otro uso muy común para Web Proxies es hacer que realicen la función de caché.
o Esto hace que el proxy, después de acceder a una página, almacene el contenido de la misma en su
sistema.
o Después de eso, las otras solicitudes a esta misma página no tendrán que ir a Internet, porque el
contenido ya está almacenado en la memoria del proxy.

53
 ¿PARA QUE SIRVE UN SERVIDOR PROXY?

o CONTROL DE ACCESO: Es posible que los administradores del servidor proxy permitan que ciertos
usuarios tengan o no acceso a Internet a través de restricciones en su propio inicio de sesión o
direcciones IP, proporcionando al entorno una capa adicional de protección.

o FILTRADO DE CONTENIDO: Al estar en el medio del camino, el servidor también permite, o no, el
acceso a ciertos sitios.
▪ Entre las reglas que se pueden aplicar están aquellas para bloquear sitios web específicos,
pudiendo llegar a bloquear categorías completas.

PROXY INVERSO

• Otro uso muy común son los servidores de proxy inverso.

• En los ejemplos anteriores, el origen de la conexión siempre estuvo dentro de la red, pasaba por el proxy
hasta Internet.
• En el caso del proxy inverso, el origen de las solicitudes está en Internet y busca acceder a un servidor dentro
del entorno, como se muestra a continuación:

• Los proxys inversos se usan comúnmente para manejar solicitudes a servidores que alojan páginas web.
• Algunos de los beneficios de utilizarlos de esta manera son:

o EQUILIBRIO DE CARGA: Debido a que la estructura del servidor proxy inverso le permite conectarse a
varios servidores de destino, puede dirigir las solicitudes a cada uno de ellos sin sobrecargar ninguna.
▪ Como otra característica de seguridad, las solicitudes de Internet conocerán solo la dirección
IP del proxy y no todos los servidores y páginas que tiene la compañía.

o CACHÉ: Como en el ejemplo de caché web, los servidores proxy también se utilizan para optimizar las
solicitudes entre origen y destino.
▪ El servidor proxy inverso almacena elementos de página almacenados en servidores internos,
buscando actualizaciones de contenido de vez en cuando, para que los servidores de página
reciban incluso menos solicitudes de red, lo que les permite funcionar aún mejor.

54
PROXY PARA TODOS

• No podemos hablar de proxy sin hablar de proxies gratuitos.

• Son páginas web, como https://free-proxy-list.net/ , que proporcionan direcciones de servidores proxy en
todo el mundo “Absolutamente gratis”.
• Cualquier persona en Internet puede realizar la configuración adecuada en su navegador y utilizar el servidor
ofrecido para navegar por la web.
• Si la duda es para qué alguien puede querer esto, las respuestas son diversas.
• El uso de un proxy hace que todas las solicitudes sean hechas por el servidor proxy, no por tu enlace de
Internet, eso hace que el proveedor de tu servicio a Internet (ISP) no sepa a qué destinos de Internet te estás
dirigiendo.
• ADVERTENCIA: La frase “Totalmente gratis” está entre comillas porque, en general, las empresas y las
personas que ofrecen servidores proxy completamente abiertos en Internet están obteniendo algún tipo de
beneficio.
o Es importante recordar que, aunque el ISP no tiene acceso a las direcciones a las que accedes, el
servidor proxy sabe todo lo que los usuarios hacen y puede usar esta información para los más
diversos fines, como distribuir publicidad, interceptar contenido para realizar análisis de
comportamiento, recopilar información y otros fines, maliciosos o no.

• TOR: Tor (The Onion Router) es una herramienta que permite la conexión encadenada a múltiples servidores
proxy, lo que dificulta aún más el seguimiento de la fuente de origen.
o Fue diseñado para garantizar el acceso a la información incluso para personas en países con severas
restricciones gubernamentales sobre el acceso al contenido en Internet y funciona de manera similar
a los servidores proxy.

55
 SECURITY TESTING

SQL INJECTION

• La inyección de SQL es un tipo de ciberataque encubierto en el cual un hacker inserta código propio en un
sitio web con el fin de quebrantar las medidas de seguridad y acceder a datos protegidos.
o Una vez dentro, puede controlar la base de datos del sitio web y secuestrar la información de los
usuarios.

• Las inyecciones de SQL (o SQLI) se producen cuando el hacker introduce o inyecta en el sitio web código SQL
malicioso, un tipo de malware que se conoce como la carga útil, y consigue subrepticiamente que envíe ese
código a su base de datos como si de una consulta legítima se tratara.
• Los hackers recurren a los ataques de inyección de SQL con el fin de introducirse en la base de datos de un
sitio web.
o A veces solo quieren eliminar datos para provocar el caos y, en otras ocasiones, lo que buscan es
editar la base de datos, especialmente en el caso de sitios web financieros.

• Si un sitio web no toma las medidas adecuadas para sanear la introducción de datos, un hacker puede
inyectar el código SQL que quiera.
o De este modo, el sitio web envía el código del hacker, la carga útil, a su servidor.
o Cuando llega a la base de datos del sitio web, ubicada en su servidor, la carga útil del hacker entra en
acción e interfiere en la base de datos, de modo que el hacker puede cumplir sus objetivos.

FUZZING SCAN

• El escaneo Fuzzing verifica cómo se comporta su servicio cuando recibe una entrada aleatoria.
• Por lo general, un atacante intenta lanzar valores aleatorios para provocar un comportamiento inesperado en
las operaciones del servicio web, por lo que el servicio revela los datos del sistema a través de mensajes de
error o seguimientos de pila.
• El escaneo Fuzzing verifica cómo actúa su servicio en tales casos enviando datos de entrada totalmente
aleatorios repetidamente durante un período prolongado de tiempo.
• Si el escaneo no revela ninguna información sobre posibles vulnerabilidades, pasa exitosamente.
• Si el escaneo ha fallado, eso puede significar que hay inestabilidades en su servicio o que las solicitudes
iterativas causan problemas de seguridad o revelan datos confidenciales.
• El término "Fuzzing" tiene un significado amplio en el dominio de las pruebas de seguridad, pero más
comúnmente se usa para describir la práctica de generar entradas aleatorias para un sistema de destino, por
ejemplo, activando clics aleatorios del mouse y del teclado para la interfaz de usuario o creando datos de
entrada totalmente aleatorios a algún tipo de sistema.
o Al hacer esto repetidamente durante un período prolongado de tiempo, el "ataque" fuzzing se
esfuerza por descubrir inestabilidades en el sistema de destino que no se descubren mediante un
proceso de prueba más estructurado.

• El Fuzzing Scan genera una entrada totalmente aleatoria para los parámetros de solicitud especificados para
un número específico de solicitudes, con la esperanza de provocar algún tipo de inesperado.
o Por defecto, los valores generados tendrán entre 5 y 15 caracteres de longitud y mutarán 100 veces;
una prueba de fuzzing más realista podría cambiar estas configuraciones para que estén entre 0 y 100
caracteres para 100000 solicitudes.
o Por supuesto, esto puede llevar algún tiempo, pero será más en el "espíritu" de la confusión.

56
XPATH INJECTION

• Ataque a servidores web mediante peticiones XPath.

• Se trata de desconcertar al servidor cuando analiza el sentido de la consulta XPath, provocando la revelación
de contenido XML al cual no se debería tener acceso.
• De manera similar a las inyecciones de SQL, ataques de inyección XPath se producen cuando un sitio web
utiliza la información suministrada por el usuario para construir una consulta XPath para datos XML.
• Mediante el envío de sentencias intencionalmente mal formadas, un atacante puede descubrir cómo se
estructuran los datos XML, incluso acceder a todos sus datos.
• El atacante incluso puede ser capaz de elevar sus privilegios en el sitio web si los datos XML se utilizan para la
autentificación (Como un archivo de usuario basado en XML).
• El ataque de inyección XPath se refiere al uso de las funciones de entrada suelta y tolerancia a fallas del
analizador XPath para adjuntar códigos de consulta XPath maliciosos a URL, formularios u otra información
para obtener acceso a la información de permisos y cambiar esta información.
• El ataque de inyección XPath es un nuevo método de ataque para aplicaciones de servicios web que permite
a un atacante obtener el contenido completo de un documento XML a través de una consulta XPath sin
conocer de antemano el conocimiento relevante de la consulta XPath.
• Los ataques de inyección XPath se realizan principalmente mediante la construcción de entradas especiales.
o Estas entradas suelen ser una combinación de sintaxis XPath.
o Estas entradas se pasarán a la aplicación web como parámetros, y el intruso realizará las operaciones
que el intruso desee mediante la ejecución de consultas XPath.

• A continuación, se muestra una verificación de inicio de sesión Tome el módulo como ejemplo para ilustrar el
principio de realización del ataque de inyección XPath.
o En el procedimiento de verificación de inicio de sesión de una aplicación web, generalmente hay dos
parámetros, un nombre de usuario y una contraseña, y el programa realizará operaciones de
autorización a través del nombre de usuario y la contraseña enviados por el usuario.
o Si los datos de autenticación se almacenan en un archivo XML, el principio es autorizar el acceso
buscando el nombre de usuario (nombre de usuario) y la contraseña (contraseña) en la tabla de
usuarios.
o Existe un ejemplo en el archivo user.xml de la siguiente manera:

57
 o La declaración de consulta típica en XPath es la siguiente:
▪ //users/user[loginID/text()='xyz'and password/text()='123test']

o Sin embargo, los siguientes métodos se pueden utilizar para implementar ataques de inyección para
evitar la autenticación.
▪ Si el usuario ingresa un nombre de usuario y una contraseña, por ejemplo, loginID = 'xyz' y
contraseña = '123test', la declaración de consulta devolverá verdadero.
▪ Pero si el usuario pasa un valor como 'o 1 = 1 o' '=', la declaración de consulta también
obtendrá un valor de retorno verdadero, porque la declaración de consulta XPath
eventualmente se convertirá en el siguiente código:
➢ //users/user[loginID/text()=''or 1=1 or ''='' and password/text()='' or 1=1 or ''='']

o Esta cadena lógicamente hará que la consulta siempre devuelva verdadero y siempre permitirá que el
atacante acceda al sistema.
o Los atacantes pueden usar XPath para manipular dinámicamente documentos XML en la aplicación.
o Una vez que se completa el ataque, los usuarios pueden obtener la cuenta de la más alta autoridad y
otra información importante del documento a través de la tecnología de entrada ciega XPath.

INVALID TYPES

• Intenta aprovechar el manejo de datos de entrada no válidos.

• Al implementar servicios web, es fácil olvidar el manejo de valores que no espera, especialmente si la entrada
ya está restringida en el lado del cliente.
• El análisis de tipos no válidos está diseñado para ayudarlo a asegurarse de que su servidor maneja este tipo
de situaciones con elegancia.
• Al lanzar valores que están diseñados para causar un comportamiento inesperado en las operaciones del
servicio web, los atacantes pueden conseguir que el servidor de destino les brinde información útil del
sistema (Generalmente a través de mensajes de error o seguimiento de pila).
• El análisis de Tipos no válidos comprueba cómo se comporta su servicio cuando obtiene valores de tipos
inesperados.
• Por lo general, los atacantes intentan arrojar valores de tipos no válidos para hacer que el servicio revele los
datos del sistema a través de mensajes de error o seguimientos de pila.
• El análisis de tipos no válidos simula este procedimiento y le notifica sobre una posible vulnerabilidad.
• Si el escaneo no revela ninguna información sobre posibles vulnerabilidades, pasa exitosamente.
• Si el escaneo ha fallado, eso puede indicar que su servicio es vulnerable a tipos de valores inesperados y
expone información confidencial.

58
BOUNDARY SCAN

• Intenta aprovechar el mal manejo de valores que están fuera de los rangos definidos.
• Al arrojar valores que están fuera de los límites esperados en las operaciones de servicios web, los atacantes
pueden conseguir que el servidor de destino les brinde información útil del sistema (Generalmente a través
de mensajes de error o trazas de pila).
• El escaneo de límites verifica si su servicio maneja correctamente los valores de entrada inesperados.
• Por lo general, los atacantes intentan enviar valores que están fuera del rango esperado, lo que hace que el
servicio revele los datos del sistema a través de mensajes de error o seguimientos de pila.
• El escaneo de límites verifica cómo actúa su servicio en tales casos enviando varias entradas inesperadas.
• Por ejemplo, para un campo de entrada que acepta cualquier valor entero entre 1y 10, el escaneo de límites
verifica su comportamiento si un usuario ingresa 20o -5.
• Al ser la prueba basada en datos ejecutada en un bucle, reemplaza los valores existentes por otros nuevos.
• Si el escaneo no revela ninguna información sobre posibles vulnerabilidades, pasa exitosamente.
• Si el escaneo ha fallado, eso puede significar que su servicio es sensible a valores que caen fuera del rango
normal y sus vulnerabilidades están expuestas.
• El escaneo de límites reemplaza los parámetros originales de un paso de prueba o una solicitud con valores
que violan los límites definidos en la definición del servicio web.
• Actualmente, el escaneo de límites identifica y procesa los siguientes límites:
o xsd:min
o xsd:max
o xsd:length
o xsd:minInclusive
o xsd:maxInclusive
o xsd:minExclusive
o xsd:maxExclusive
o xsd:totalDigits
o xsd:fractionDigits

MALFORMED XML

• Al enviar XML con formato incorrecto especialmente diseñado, un atacante podría bloquear un servidor
vulnerable o incluso ejecutar comandos arbitrarios en el servidor.
• El objetivo de un ataque suele ser provocar que el servidor de destino exponga información confidencial o se
bloquee.
• El Escaneo de seguridad XML con formato incorrecto enviará una modificación de la solicitud de destino
insertando fragmentos XML con formato incorrecto, dejando elementos o atributos abiertos, agregando
atributos no definidos, etc.
• El escaneo de XML con formato incorrecto comprueba cómo se comporta su servicio cuando recibe
fragmentos de XML con formato incorrecto.
• Normalmente, los atacantes intentan enviar un XML con formato incorrecto para bloquear un servidor
vulnerable o ejecutar comandos arbitrarios. Por ejemplo, el siguiente código:

59
XML BOMB

• Una bomba XML es un mensaje redactado y enviado con la intención de sobrecargar un analizador XML
(Normalmente un servidor HTTP).
• Una bomba XML es un fragmento de código pequeño pero peligroso que se escribe y envía con la intención
de bloquear el servidor o programa objetivo que intenta leerlo y decodificarlo.
o Cuando un analizador XML intenta procesar una bomba XML, las entidades de datos anidadas
comienzan a crecer exponencialmente.
o Esto puede resultar en el cierre de un servidor o ISP, haciéndolo vulnerable al acceso no autorizado
por piratas informáticos, lo que puede resultar en una seria amenaza a la privacidad de los datos.
o Una bomba XML aprovecha tres propiedades de XML, a saber, sustitución de entidades, entidades
anidadas y DTD en línea, para provocar una "explosión de datos", de ahí la "bomba" en el nombre.

• Las bombas XML aprovechan el hecho de que XML permite definir entidades.
• Normalmente, los atacantes intentan utilizar una bomba XML para provocar retrasos en la respuesta del
servicio e inestabilidad general que conduce a la denegación del servicio.
• El escaneo de bombas XML crea una bomba de este tipo para garantizar que los ataques de ese tipo no
causen un daño significativo.
o Por ejemplo, el siguiente fragmento XML denegará el servicio de un servidor vulnerable y
posiblemente provocará un bloqueo:

60
CROSS SITE SCRIPTING

• Cross-site Scripting, comúnmente abreviado XSS, es probablemente la vulnerabilidad de seguridad de sitios

web más común.
o Permite a un atacante inyectar secuencias de comandos del lado del cliente (Por ejemplo, Javascript,
VBScript o Flash) en las páginas web vistas por otros usuarios.

• El método es muy similar a SQL Injection y XPath Injection, pero el objetivo son los usuarios de un sitio web
en lugar del sitio web en sí.
• XSS es un vector de ataque que puede ser utilizado para robar información delicada, secuestrar sesiones de
usuario, y comprometer el navegador, subyugando la integridad del sistema.
• Las vulnerabilidades XSS han existido desde los primeros días de la Web.2
o Esta situación es habitualmente causada al no validar correctamente los datos de entrada que son
usados en cierta aplicación, o no sanear la salida adecuadamente para su presentación como página
web.

• Una secuencia de comandos en sitios cruzados o Cross-site scripting (XSS por sus siglas en idioma inglés) es
un tipo de vulnerabilidad informática o agujero de seguridad típico de las aplicaciones Web, que puede
permitir a una tercera persona inyectar en páginas web visitadas por el usuario código JavaScript o en otro
lenguaje similar (Ej: VBScript).1 Se puede evitar usando medidas como CSP, política del mismo origen,
etcétera.
• Es posible encontrar una vulnerabilidad de Cross-Site Scripting en aplicaciones que tengan entre sus
funciones presentar la información en un navegador web u otro contenedor de páginas web.
o Sin embargo, no se limita a sitios web disponibles en Internet, ya que puede haber aplicaciones
locales vulnerables a XSS, o incluso el navegador en sí.

MALICIOUS ATTACHMENT

• El análisis de archivos adjuntos maliciosos genera archivos corruptos para verificar cómo se comporta su
servicio al recibir archivos maliciosos.
• Por lo general, los atacantes adjuntarán archivos maliciosos a una solicitud con uno de estos propósitos:
o Intentando hacer que el servidor se bloquee con archivos corruptos o muy grandes.
o Dañar servidores con virus o archivos que contienen código dañino.
o Pasar virus o archivos que contienen código dañino a través del servidor, cuando el objetivo del
ataque es un cliente.

• Dicho esto, un ejemplo podría cargar una imagen JPEG dañada a una galería web, con la intención de
bloquear el servidor web.
o Cuando el objetivo son los usuarios finales, un archivo adjunto malicioso se puede enmascarar para
que parezca un archivo inofensivo, por ejemplo, hilariousPhoto.jpg.com (Los archivos con la
extensión de archivo COM son ejecutables en Microsoft Windows).

61
 PREGUNTAS DE ENTREVISTA

• ¿QUÉ SON LAS WEBSERVICES?: Es una aplicación o lógica de negocio que es accesible mediante protocolos
estándares de internet como el protocolo de sistema de mensajería XML.
o Un web service es una vía de intercomunicación e interoperabilidad entre máquinas conectadas en
Red.
o la interacción se basa en el envío de solicitudes y respuestas entre un cliente y un servidor, que
incluyen datos.
o El cliente solicita información, enviando a veces datos al servidor para que pueda procesar su
solicitud.
o El servidor genera una respuesta que envía de vuelta al cliente, adjuntando otra serie de datos que
forman parte de esa respuesta.
o Por tanto, podemos entender un servicio web como un tráfico de mensajes entre dos máquinas.

• ¿QUÉ SON LAS API?: Una API de transferencia de estado representacional (REST), o API de RESTful, es una
interfaz de programación de aplicaciones (API o API web) creada por el informático Roy Fielding, la cual se
ajusta a los límites de la arquitectura REST y permite la interacción con los servicios web de RESTful.
o Una API es un conjunto de definiciones y protocolos que se utiliza para desarrollar e integrar el
software de las aplicaciones.
o Suele considerarse como el contrato entre el proveedor de información y el usuario, donde se
establece el contenido que se necesita del consumidor (La llamada) y el que requiere el productor (La
respuesta).
o Por ejemplo, el diseño de una API para un servicio meteorológico podría solicitar que el usuario
escribiera un código postal y que el productor diera una respuesta en dos partes: La primera sería la
temperatura máxima y la segunda, la mínima.
o En otras palabras, si desea interactuar con una computadora o un sistema para obtener datos o
ejecutar una función, las API le permiten comunicar lo que desea al sistema, para que este
comprenda la solicitud y la cumpla.
o Imagine la API como si fuera el mediador entre los usuarios o clientes y los recursos o servicios web
que quieren obtener.
▪ Con ellas, las empresas pueden compartir recursos e información y mantener la seguridad, el
control y la autenticación, lo cual les permite determinar el contenido al que puede acceder
cada usuario.

o Otra ventaja de las API es que usted no necesita saber cómo se recibe el recurso ni de dónde
proviene.

• ¿QUÉ ES WSDL?: WSDL es una notación XML para describir un servicio web.
o Una definición WSDL indica a un cliente cómo componer una solicitud de servicio web y describe la
interfaz que proporciona el proveedor del servicio web.
o Describe como acceder al Web Service y que operaciones se pueden realizar.
o Es muy usado en combinación con SOAP y XML para proveer Web Services de internet.

• ¿QUÉ ES UN ENDPONIT?: Es la dirección IP del servidor donde se está ejecutando el Webservice.

62
• ¿QUÉ SON LAS API REST?: Significa Representational State Transfer, y es una API donde usamos métodos
HTTP estándares para acceder a sus recursos como: GET, POST, DELETE y PUT.
o Un servicio REST no es una arquitectura software, sino un conjunto de restricciones que tener en
cuenta en la arquitectura software que usaremos para crear aplicaciones web respetando HTTP.
o Según Fielding las restricciones que definen a un sistema RESTful serían:
▪ Cliente-servidor: El servidor se encarga de controlar los datos mientras que el cliente se
encarga de manejar las interacciones del usuario. Esta restricción mantiene al cliente y al
servidor débilmente acoplados (el cliente no necesita conocer los detalles de implementación
del servidor y el servidor se “despreocupa” de cómo son usados los datos que envía al
cliente).
▪ Sin estado: aquí decimos que cada petición que recibe el servidor debería ser independiente
y contener todo lo necesario para ser procesada.
▪ Cacheable: debe admitir un sistema de almacenamiento en caché. Este almacenamiento
evitará repetir varias conexiones entre el servidor y el cliente para recuperar un mismo
recurso.
▪ Interfaz uniforme: define una interfaz genérica para administrar cada interacción que se
produzca entre el cliente y el servidor de manera uniforme, lo cual simplifica y separa la
arquitectura. Esta restricción indica que cada recurso del servicio REST debe tener una única
dirección o “URI”.
▪ Sistema de capas: el servidor puede disponer de varias capas para su implementación. Esto
ayuda a mejorar la escalabilidad, el rendimiento y la seguridad.

• ¿QUÉ ES PROPERTY TRANSFER EN SOAPUI?: Es lo que nos deja transferir los valores de la respuesta de una
API a la petición de otra API.

• ¿QUÉ TIPO DE SCRIPTING SOPORTA SOAPUI?: Groovy scripting, Java y JavaScript.

• ¿CUÁLES SON LOS OBJETOS DE LA VENTANA DE SCRIPT ASSERTION EN SOAPUI?: Log, context y
messageExchange.

• ¿CUÁL ES EL USO DE TESTRUNNER EN SOAPUI?: Con la ayuda de la variable TestRunner podemos tener
control sobre los casos de prueba de una test suite y métodos a nivel de proyecto y acceso a sus propiedades.

• ¿QUÉ TIPOS DE ARCHIVOS DE ENTRADA Y SALIDA SOPORTAN LAS API REST?: Soportan archivos XML y Json.

• ¿QUÉ ES MOCKING?: Los servicios Mock son la mejor manera de comenzar a testear de forma temprana la
imagen de un proyecto orientado a servicios.
o Una vez el WSDL del Web service está listo, podemos simular la implementación del servicio y
comenzar a testear las aplicaciones del consumidor.

63
 OTROS

• El FrontEnd al fin y al cabo es un cliente igual que las API.

• Cuando no mandemos ningún body no necesitamos especificar el header Content-Type en la petición.

64
 TÉRMINOS

• MONOLITOS: Son aplicaciones o programas que están todos juntos, es decir, la lógica de datos, la interfaz de
usuario, etc.

• HOSTER: El término host o anfitrión se usa en informática para referirse a las computadoras u otros
dispositivos (Tabletas, móviles, portátiles) conectados a una red que proveen y utilizan servicios de ella.
o Los servidores deben utilizar anfitriones para tener acceso a la red y pueden, a su vez, pedir los
mismos servicios a otras máquinas conectadas a la red.
o Los anfitriones son, por tanto, dispositivos monousuario o multiusuario que ofrecen servicios de
transferencia de archivos, conexión remota, servidores de base de datos, servidores web, etc.
o De forma genérica, podemos decir que un anfitrión es todo equipo informático que posee una
dirección IP y que se encuentra interconectado con uno o más equipos y que funciona como el punto
de inicio y final de las transferencias de datos.1
o También es descrito como el lugar donde reside un sitio web, un anfitrión de Internet tiene por lo
general una dirección de Internet única llamada "dirección IP" y un nombre de dominio único o
nombre de anfitrión (host name).

65