Resultados de búsqueda para REST

Los servicios web suelen imponer dependencias entre parámetros (también llamadas dependencias inter-parámetro) que restringen el modo en que dos o más parámetros de entrada pueden combinarse para formar una llamada válida. Desafortunadamente, los lenguajes de especificación de servicios web actuales como OpenAPI Specification (OAS) no proporcionan soporte para describir dichas dependencias formalmente, lo que dificulta enormemente la interacción con estos servicios de forma automática, sin necesidad de intervención humana. En este artículo, presentamos una estrategia para la especificación y el análisis automático de dependencias inter-parámetro en APIs web. En primer lugar, presentamos un lenguaje específico de dominio (DSL), llamado Inter-parameter Dependency Language (IDL), para la especificación de dependencias entre parámetros en servicios web. A continuación, proponemos un mapping para traducir un documento IDL a un problema de satisfacción de restricciones (CSP), habilitando el análisis automático de especificaciones IDL mediante operaciones de razonamiento estándar basadas en CSP. Concretamente, presentamos un catálogo de siete operaciones de análisis en documentos IDL permitiendo, por ejemplo, comprobar si una determinada petición satisface todas las dependencias del servicio. Por último, presentamos una suite de herramientas para la especificación y el análisis de IDL, incluyendo un editor, un parser, una extensión de OAS, una librería basada en programación con restricciones, y una completa suite de pruebas. En conjunto, estas contribuciones sientan las bases de una nueva generación de aplicaciones en áreas tales como generación automática de código y pruebas de servicios web.

Las técnicas de pruebas automatizadas para APIs REST suelen seguir un enfoque de caja negra, donde los casos de prueba se derivan de la especificación de la API. Estas técnicas muestran resultados prometedores, pero ignoran las restricciones entre los parámetros de entrada de la API (llamadas dependencias inter-parámetro), ya que estas no pueden describirse formalmente en los lenguajes de especificación actuales. Como resultado, las herramientas de caja negra recurren a la fuerza bruta para la generación de casos de prueba válidos, es decir, aquellos que satisfacen todas las dependencias inter-parámetro. Esto no es solo extremadamente ineficiente, sino que además es improbable que funcione con muchos servicios del mundo real, donde las dependencias inter-parámetro son complejas y abundantes. En este artículo, presentamos RESTest, un framework de pruebas automatizadas de caja negra para APIs REST. Entre sus principales características, RESTest soporta la especificación y el análisis automático de las dependencias inter-parámetro de la API, lo que permite utilizar resolutores de restricciones para la generación automática de casos de prueba válidos. Esto permite detectar más errores, y más rápido, mediante una evaluación más exhaustiva de las combinaciones válidas e inválidas de los parámetros de la API, y el uso de oráculos de prueba antes no disponibles. Los resultados de nuestra evaluación en 6 APIs comerciales muestran que RESTest puede generar de manera eficiente hasta un 99+ACU más de casos de prueba válidos en comparación con técnicas de pruebas aleatorias, un 60+ACU de media. Lo que es más importante, RESTest revel+APM más de 2.000 fallos no detectados por pruebas aleatorias, encontrando errores en todos los servicios probados.

Nowadays, many developers around the world use RESTful APIs along microservices architectures. These APIs are increasingly being described using the OpenAPI Specification standard. Moreover, they usually require some level of security. However, maintaining security settings across the entire architecture can be a time-consuming task. For example, adding a new role to the application may lead to modifying the settings for each API. This approach presents various drawbacks, such as low scalability. We have found this problem while working on an institutional web page. This is why we are developing an extension for OpenAPI which allows for easier security management on microservices applications. Furthermore, the in-progress Node.js module will perform automatic validation of JSON Web Tokens. JWTs are a simple and standard way to implement access control. Using them along with the aforementioned extension will greatly reduce development time. By providing some configuration parameters, a single API or a whole infrastructure will be more secure. This will also cause bigger applications to be more scalable and easy to maintain.

Web APIs following the REST architectural style (so-called RESTful Web APIs) have become the de-facto standard for software integration. As RESTful APIs gain momentum, so does the testing of them. However, there is a lack of mechanisms to assess the adequacy of testing approaches in this context, which makes it difficult to measure and compare the effectiveness of different testing techniques. In this work-in-progress paper, we take a step forward towards a framework for the assessment and comparison of testing approaches for RESTful Web APIs. To that end, we propose a preliminary catalogue of test coverage criteria. These criteria measure the adequacy of test suites based on the degree to which they exercise the different input and output elements of RESTful Web services. To the best of our knowledge, this is the first attempt to measure the adequacy of testing approaches for RESTful Web APIs.

En los últimos años, la industria del software ha apostado por la migración hacia las aplicaciones basadas en servicios y su despliegue en la nube por su promesa de obtener alta disponibilidad y escalabilidad. Tanto las aplicaciones Web como las móviles utilizan partes servidoras basadas en fachadas REST o SOA que en muchas ocasiones crecen tanto a nivel de servicios como de datos lo que complica su mantenibilidad. En este sentido, ha aparecido recientemente un estilo arquitectónico denominado microservicios que propone la división horizontal de la funcionalidad de una aplicación en una colección de servicios que gestionan separadamente su propia lógica y sus datos. Esta división permite explotar la escalabilidad de la nube a nivel de servicio y abordar los cambios más rápidamente. A pesar de sus beneficios, este estilo arquitectónico presenta algunas desventajas como la dificultad de agregar datos de diferentes microservicios y el mantenimiento de la consistencia entre las diferentes orígenes de datos. Para abordar estos dos retos, este trabajo presenta una solución MDE basada en una evolución del modelo de servicios de OOH4RIA. Este modelo permite tanto acelerar la creación de microservicios como facilitar el mantenimiento en la comunicación y la composición de datos de diferentes orígenes.

Existe una gran problemática alrededor de personas enfermas de Alzheimer. Estas personas viven en el pasado y no son conscientes de la reali-dad en la que viven. Gran parte de ellas llegan a perderse provocando un gran dolor en familia y amigos. Por consiguiente, el ser informado en el instante jus-to que dicha persona abandona su hogar, la residencia o lugar de recreo evitaría muchas situaciones trágicas para estas familias. En este artículo desarrollamos un sistema que integra SOA 2.0 con un motor de procesamiento de eventos complejos y un sensor GPS con el fin de avisar a los familiares en el momento en que el enfermo salga de una zona determinada. Los resultados obtenidos de-muestran que el procesamiento de eventos complejos es la tecnología acertada para detectar en tiempo real cuándo una persona abandona una zona establecida y ser informados de su posición, pudiendo emprender su búsqueda inmediata-mente y evitar la fatal pérdida.

onitorizar los Indicadores Clave de Desempeño en una organización es un aspecto clave que nos permite adoptar decisiones estratégicas basadas en información cuantitativa fidedigna. En la Inteligencia de Negocio (Business Intelligence, BI) tradicional, el análisis es una tarea compleja, ya que si un indicador falla no se conocen claramente todos los objetivos de negocio que están siendo afectados. A estas dificultades ha de añadirse el uso, cada vez más habitual, de datos externos, que suelen estar hospedados por terceras partes. De esta forma el análisis se convierte en una amalgama de datos heterogéneos proporcionados por Indicadores Internos y Externos que, difícilmente se encuentran alineados con la estrategia de negocio y, por tanto, dificultan aún más el control de los procesos. En este artículo, proponemos una aproximación para permitir la integración Indicadores Externos e Internos de la empresa. Gracias a nuestra aproximación se podrá consultar datos de fuentes externas junto las internas y por tanto, se simplifica la tarea de análisis.