{"id":15648605,"url":"https://github.com/mdelapenya/uned-sensors-wedeploy","last_synced_at":"2026-05-15T12:03:08.862Z","repository":{"id":141610093,"uuid":"82978415","full_name":"mdelapenya/uned-sensors-wedeploy","owner":"mdelapenya","description":null,"archived":false,"fork":false,"pushed_at":"2017-08-08T11:06:32.000Z","size":3809,"stargazers_count":1,"open_issues_count":2,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-03-29T23:41:32.397Z","etag":null,"topics":["iot","spring-boot","uned","wedeploy"],"latest_commit_sha":null,"homepage":null,"language":"CSS","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/mdelapenya.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2017-02-23T22:39:51.000Z","updated_at":"2024-07-02T19:44:09.000Z","dependencies_parsed_at":"2023-06-26T00:28:00.755Z","dependency_job_id":null,"html_url":"https://github.com/mdelapenya/uned-sensors-wedeploy","commit_stats":null,"previous_names":[],"tags_count":2,"template":false,"template_full_name":null,"purl":"pkg:github/mdelapenya/uned-sensors-wedeploy","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mdelapenya%2Funed-sensors-wedeploy","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mdelapenya%2Funed-sensors-wedeploy/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mdelapenya%2Funed-sensors-wedeploy/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mdelapenya%2Funed-sensors-wedeploy/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/mdelapenya","download_url":"https://codeload.github.com/mdelapenya/uned-sensors-wedeploy/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/mdelapenya%2Funed-sensors-wedeploy/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":271306841,"owners_count":24736775,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-08-20T02:00:09.606Z","response_time":69,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["iot","spring-boot","uned","wedeploy"],"created_at":"2024-10-03T12:25:28.832Z","updated_at":"2026-05-15T12:03:03.841Z","avatar_url":"https://github.com/mdelapenya.png","language":"CSS","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Práctica Sensores y Plataformas\n\n    Alumno: Manuel de la Peña\n    D.N.I.: 53.430.012-T\n    Asignatura: Computación Ubícua\n    Máster de Investigación en Ingeniería del Software y Sistemas Informáticos\n    Curso: 2016-2017\n    Universidad Nacional de Educación a Distancia (U.N.E.D.)\n\nPara acceder en modo online a este documento, por favor visite [el siguiente enlace](https://github.com/mdelapenya/uned-sensors-wedeploy/blob/master/README.md)\n\n## Enunciado de la práctica\n\nEstudiar y proponer la integración de información sensorial sobre una plataforma de servicio para el\nInternet de las Cosas (IoT).\n\n## Descripción de la práctica\n\nLa práctica consiste en la utilización de las plataformas para el Internet de las Cosas para integrar\ninformación sensorial (preferiblemente con el sensor definido en la PEC2, MIVELOCIDAD1) y proponer una\naplicación sobre la plataforma elegida con esta información.\n\nSe puede utilizar cualquiera de las siguientes plataformas OpenSource:\n\n* Kaa: Independiente de plataforma - C SDK [https://www.kaaproject.org](https://www.kaaproject.org)\n* Macchina.io: Linux - JavaScript/C++ [https://macchina.io](https://macchina.io)\n* Iotivity: Independiente de plataforma - C/C++ [https://www.iotivity.org](https://www.iotivity.org)\n* SiteWhere: Linux - Java [http://www.sitewhere.org](http://www.sitewhere.org)\n\nTambién es posible utilizar otro tipo de plataforma no OpenSource como puede ser principalmente Autodesk\nFusion Connect, AWS (Amazon Web Services), Google Cloud IoT, Microsoft Azure IoT, IBM Watson IoT o\nThingWorx, teniendo en cuenta las limitaciones correspondientes a cada caso en las versiones \"free\".\n\n## Arquitectura de la solución\n\nLa solución constará de 2 desarrollos independientes: por un lado la aplicación Android desarrollada\ncon anterioridad, para representar los cambios de velocidad y posición del GPS del dispositivo móvil\nen el que se instala, y por otro lado el desarrollo de una plataforma IoT donde se almacenarán y\nrepresentarán las métricas enviadas por los dispositivos que instalen la aplicación.\n\nPara consultar la documentación relativa a la aplicación Android desarrollada con anterioridad, actualizada\ncon el desarrollo necesario para comunicarse con la plataforma IoT, puede seguirse [el siguiente enlace](https://github.com/mdelapenya/uned-sensors/blob/master/README.md).\n\nEn el escenario del trabajo propuesto, y por simplicidad, se ha optado por desarrollar una plataforma\nIoT específica para el trabajo, que constará de tres piezas, todas alojadas en un PaaS (*Platform as\na Service*) representando la plataforma IoT:\n\n* API REST para manejar los recursos asociados a métricas: envío y consulta de métricas.\n* Almacenamiento persistente de métricas.\n* Interfaz de usuario para la visualización de las métricas almacenadas.\n\nCada pieza será representada por un microservicio, de modo que éste pueda ser evolucionado y escalado\nde manera independiente. Será la plataforma IoT la que ofrezca las capacidades de **Registro** y\n**Descubrimiento de servicios** de manera transparente al desarrollador: simplemente por estar\ndesplegadas las aplicaciones en la plataforma, éstas tendrán visibilidad las unas con las otras.\n\n## Plataforma IoT\n\nPara la implementación de la plataforma se ha obtado por realizar un desarrollo propio a medida, en\nlugar de utilizar una plataforma ya consolidada como podría ser `Kaa Platform`. La principal razón\nde utilizar este enfoque es el de desarrollar la plataforma desarrollada de manera específica para la\nlectura de métricas desde los sensores, sin tener que aprender a utilizar, configurar y operar un\nsistema de terceros por completo. Por ello, se ha elegido utilizar un PaaS como es [WeDeploy](http://www.wedeploy.com),\nque permite desplegar servicios en su plataforma, gestionando dichos servicios como repositorios Git.\n\n### Motivación sobre la elección de WeDeploy\n\nLa motivación más importante es la que se refiere a la infraestructura. Mientras que con otras\nplataformas como `Kaa` o `Macchina.io` es necesaria la instalación y configuración de la máquina base\nque dará soporte a la plataforma, con **WeDeploy** nos olvidamos completamente de la infraestructura,\nayudando al desarrollador de aplicaciones, en este caso de IoY, a dedicar el tiempo a lo que realmente\nimporta: construir y escalar aplicaciones.  \n\n#### ¿Qué es WeDeploy?\n\nWeDeploy proporciona un acceso a APIs muy intuitivas que ayudan a la creación de aplicaciones modernas,\nde una manera más rápida. Desde aplicaciones sencillas a una completa arquitectura orientada a\nmicroservicios, **WeDeploy** permite elegir entre una docena de lenguajes, frameworks, o stacks\ncompletos de aplicaciones, así como lanzar entornos preparados para producción en cuestión de minutos. \n\nCon **WeDeploy** es posible responder a las necesidades de los usuarios de una manera más rápida y\neficiente:\n\n* Despliegue de aplicaciones más rápido.\n* Distribución automática del tráfico entrante entre múltiples instancias.\n* Autenticación de usuarios con unas pocas líneas de código.\n* Almacenamiento seguro y consumo de información en tiempo real.\n* Lanzamiento de aplicaciones sin tiempos de caída.\n* Construcción y despliegue de microservicios.\n\n#### ¿Por qué WeDeploy?\n\nA la hora de construir aplicaciones altamente escalables, es necesario considerar muchos elementos,\ncomo por ejemplo, cuellos de botella en el rendimiento, resiliencia y escalabilidad de la base de\ndatos, autenticación, autorización, alojamiento estático, por citar unos cuantos. **WeDeploy** permite\nenfrentarse a todos los retos de un backend en un único lugar.\n\n#### ¿Cómo ayuda WeDeploy al despliegue de aplicaciones?\n\nIndependientemente de tener una aplicación sencilla, o un conjunto complejo de microservicios, la\ninfraestructura cloud gestionada que supone **WeDeploy** propociona las herramientas para manejar la\nvisibilidad, el escalado y la resolución de nombres (DNS) de las aplicaciones.\n\n#### ¿Qué funcionalidades ofrece WeDeploy?\n\n##### Actualizaciones sin tiempos de caída\n\n**WeDeploy** proporciona automatización para la actualización de servicios y sistemas sin tiempo de\ncaída ni interrupciones al usuario. Los despliegues de los servicios pueden ser realizados utilizando\ndistintos algoritmos: `rolling-update`, `blue-green` o `canary`. Si la actualización falla, es posible\nvolver atrás de una manera muy sencilla (un click). \n\n##### Descubrimiento de servicios y balanceo de carga\n\nLos servicios distribuidos crean problemas distribuidos. Por ello **WeDeploy** incluye la generación\nautomática de endpoints DNS, un API para el descubrimiento de servicios, una capa de transporte (L4)\nde proxy de IPs virtuales para soportar la comunicación interna de alta velocidad, y una capa de\naplicación (L7) de balanceo de carga para los servicios expuestos hacia el exterior.\n\n##### Servicios de visibilidad\n\nCon **WeDeploy** es posible marcar los servicios como públicos o privados en cuanto al acceso externo.\n\n##### Alta disponibilidad\n\n**WeDeploy** está configurado en alta disponibilidad y facilita del mismo modo que los servicios estén\ndisponibles en alta disponibilidad del mismo modo.\n\nLos servicios críticos requieren de monitorización, auto-curado, y tolerancia a fallos, tanto para\nellos mismos como para la plataforma e infraestructura sobre la que corren. **WeDeploy** ofrece múltiples\ncapas de protección. Para consehuir el auto-curado, por ejemplo, los servicios son monitorizados y\nrelanzados si fallan. Incluso servicios de código legado que no soportan distribución o replicación\npueden ser automáticamente relanzados para maximizar el tiempo de uso, así como disminuir el número\nde interrupciones del servicio.\n\n##### Escalabilidad elástica\n\n**WeDeploy** permite escalar de manera fácil los servicios. El escalado horizontal es trivial con\nDocker Swarm, siempre y cuando los servicios lo soporten. Es posible además cambiar el número de\ninstancias en cualquier momento, incluso basándose en el número de sesiones concurrentes, mediante el\nuso del servicio de Balanceo de Carga.\n\n##### Interfaces de usuario\n\n**WeDeploy** ofrece dos interfaces para facilitar la monitorización y la gestión de los proyectos y\nservicios. Por un lado, el `Dashboard`, o cuadro de mandos, que permite monitorizar el dimensionamiento\nde los recursos, y la salud de los servicios en ejecución, entre otros, mediante el uso de un navegador\nweb, gráficos en tiempo real, y herramientas interactivas de depuración.\n\nAdemás, **WeDeploy** proporciona un CLI (`Command-line Interface`) para gestionar lose proyectos y\nservicios desde la comodidad de un terminal. Este CLI es potente, a la vez que scriptable, con varios\nplug-ins para interactuar con los proyectos.\n\n## Modelo de Datos\n\nEn cuanto al modelo de datos que manejará la plataforma, se pretende almacenar aquellos datos enviados\npor las aplicaciones que comuniquen con la misma, mediante el API expuesto por uno de los microservicios\nantes mencionados. Para ello, se definirá el siguiente modelo de datos, con las consiguientes relaciones\nentre entidades del modelo:\n\n* Un Sensor podrá enviar 1 ó N Métricas desde 1 ó N Aplicaciones.\n* Una Métrica sólo puede pertenecer a 1 Sensor, pero podrá ser enviadad desde 1 ó N Aplicaciones.\n\nDe este modo, un sensor en una aplicación podrá enviar N métricas; una métrica de un sensor podrá ser\nenviada desde N aplicaciones; y una métrica enviada desde una aplicación podrá ser leída de un único\nsensor.\n\nPor tanto, se establece una relación ternaria entre Sensor, Aplicación y Métrica, donde la clave\nprimaria vendrá definida por el identificador del sensor, el identificador de la aplicación, y los\nidentificadores de la métrica, que en este caso será la marca de tiempo asociada al envío de la\nmétrica.\n\n### Sensor\n\nÚnicamente recogeremos el identificador del sensor, por tanto la entidad sólo tendrá un campo de tipo\n`String` almacenando dicho ID único.\n\nPara el sensor representado por la aplicación Android, el identificador se obtiene de la siguiente\nmanera:\n\n```java\nprivate String getUniqueDeviceId() {\n    TelephonyManager telephonyManager =\n        (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE);\n\n    final String deviceId = telephonyManager.getDeviceId(); // identificador del dispositivo\n    final String simSerialNumber = telephonyManager.getSimSerialNumber(); // número de serie de la SIM\n    final String androidId = android.provider.Settings.Secure.getString(\n        getContentResolver(), android.provider.Settings.Secure.ANDROID_ID); // identificador de Android\n\n    UUID deviceUuid = new UUID(\n        androidId.hashCode(), ((long)deviceId.hashCode() \u003c\u003c 32) | simSerialNumber.hashCode());\n\n    return deviceUuid.toString();\n}\n```\n\nOtros sensores que quieran contribuir sus métricas a la plataforma tendrán que calcular el identificador\ndel sensor de alguna manera, por ejemplo en base al hardware del sensor.\n\n### Métricas\n\nEl dispositivo emitirá señales indicando su posición actual, expresada en coordenadas latitud y longitud,\nel valor de su métrica, el identificador de la métrica, las unidades en que se expresa la métrica, el\nidentificador de la aplicación que lo envía, y la fecha de obtención del dato, de modo que éstos serán\nenviados a la plataforma IoT por dispositivo, y almacenados en ella con cada envío.\n\nEl sensor enviará las coordenadas de su ubicación puesto que al estar instalado en un dispositivo móvil\ncomo es un terminal Android, éste podrá moverse y cambiar su ubicación.\n\n## Microservicios de la plataforma en el PaaS WeDeploy\n\nPara obtener más información sobre los microservicios desarrollados, por favor consultar los siguientes\nenlaces, relativos a cada una de los elementos software del proyecto:\n\n* [API REST](./sensors-api/README.md)\n* [Almacenamiento persistente de métricas](./sensors-data/README.md).\n* [Interfaz de usuario](./sensors-ui/README.md).\n\n## Desarrollo\n\n### Lenguaje de programación\n\nPara los microservicios alojados en **WeDeploy** se han elegido tres tecnologías diferentes: para el API\nREST se ha escogido el lenguaje Java en su versión 8, implementado mediante Spring Boot; para la\naplicación de interfaz de usuario que representará las métricas almacenadas, se ha escogido utilizar\nHTML5, CSS3 y Javascript del lado del cliente; y para el almacenamiento persistente NoSQL se ha\nutilizado `ElasticSearch`, que es el almacenamiento ofrecido de forma predefinida por el PaaS **WeDeploy**.\n\n### Sistema de Build\n\nEl único microservicio que tiene un sistema de Build es el del API, puesto que los otros dos servicios\nse refieren a contenido estático no compilado. Para acceder a la documentación de este microservicio\nde API por favor consulte [el siguiente enlace](./sensors-api/README.md#sistema-de-build).\n\n### Organización del código\n\nPara agrupar los tres microservicios que compondrán el stack de la aplicación, API REST, datos e\ninterfaz de usuario, se ha creado un único proyecto en blanco, en el que se han creado un directorio\npor cada uno de los microservicios a desarrollar.\n\nPara consultar la estructura y organización del código de cada microservicio, consulte el fichero\n`README.md` de cada servicio individual.\n\n* [API REST](./sensors-api/README.md#estructura-del-proyecto)\n* [Almacenamiento persistente de métricas](./sensors-data/README.md#estructura-del-proyecto).\n* [Interfaz de usuario](./sensors-ui/README.md#estructura-del-proyecto).\n\n## Pruebas\n\nUn requisito imprescindible en toda aplicación es la escritura de buenos tests. Se consideran como\nbuenas prácticas de escritura de tests las siguientes:\n\n* Un buen test tiene una única razón para fallar.\n* Un buen test verifica una única cosa del código a probar.\n* Un buen test evita la lógica condicional.\n* Un buen test tiene un nombre que describe de manera clara el caso de prueba. Por contra, no se puede\nconfiar en un test cuya implentación no tiene nada que ver con el nombre del método de test.\n* Un buen test crea/abre los recursos que necesita antes de su ejecución, y los cierra o borra al final\nde su ejecución.\n* Un buen test no define de manera explícita sus dependencias (*hardcoded dependencies*).\n* Un test que falla de manera constante es inútil.\n* Un test que no puede fallar no aporta valor, pues crea una falsa sensación de seguridad.\n\n### Tests unitarios\n\nDebido a la simplicidad del proyecto, no se han escrito tests unitarios para los microservicios.\n\n### Tests de integración\n\nRespecto a las pruebas de integración, se han escrito tests que prueban las llamadas HTTP al microservicio\ndel API Java, verificando que los código de respuesta HTTP son los adecuados para cada prueba.\n\nPara el lenguaje de programación de estos tests se ha elegido [`Spock`](http://spockframework.org), que es un framework de testing\ny especificación para aplicaciones Java y Groovy, inspirado en JUnit, jMock, RSpec, Groovy, Scala,\nVulcans, entre otros.\n\nEstos tests de integración, que prueban las llamadas HTTP al API, se encuentran en [este directorio](./sensors-api/src/test),\nencontrándose la documentación asociada a dichos tests igualmente en [el siguiente enlace](./sensors-api/README.md#tests).\n\n### Exploratory Testing\n\nSe han realizado pruebas exploratorias (o `Exploratory Testing`) sobre la aplicación, de modo que\ntodos los controles han sido extensamente probados, utilizando diferentes prácticas: valores límite,\nvalores incorrectos, valores nulos en los campos, etc.\n\n## Manual de Uso\n\nA continuación se presentan las diferentes pantallas de la aplicación, con la información necesaria\npara utilizar la aplicación con fluídez.\n\n### Aplicación Android\n\nEn cada cambio de posición realizado por el dispositivo Android, siempre y cuando la aplicación esté\nabierta y en primer plano, se enviará una métrica a la plataforma IoT.\n\n[Manual de uso de la aplicación Android](https://github.com/mdelapenya/uned-sensors#manual-de-uso)\n\n### Plataforma IoT\n\nA continuación se presentan las URLs de los diferentes elementos que componen la plataforma:\n\n* API (todas las métricas): [https://sensorsapi-mdelapenya.wedeploy.io/sensors](https://sensorsapi-mdelapenya.wedeploy.io/sensors)\n* API (métricas de un sensor): [https://sensorsapi-mdelapenya.wedeploy.io/sensors/ffffffff-e137-0800-d291-847505cc2b1f](https://sensorsapi-mdelapenya.wedeploy.io/sensors/ffffffff-e137-0800-d291-847505cc2b1f)\n* Interfaz de Usuario: [https://sensorsui-mdelapenya.wedeploy.io](https://sensorsui-mdelapenya.wedeploy.io)\n\n#### Obtención de todas las métricas almacenadas\n\nAccediendo a la URL [https://sensorsapi-mdelapenya.wedeploy.io/sensors](https://sensorsapi-mdelapenya.wedeploy.io/sensors), la aplicación representando el\nAPI responderá a la petición con el resultado de consultar al almacenamiento persistente sin filtros,\nde modo que devolverá todas las métricas almacenadas. La respuesta de la petición estará en formato\nJSON.\n\n![Resultados al filtrar por un sensor](static/screenshot_api_results.png)\n\n#### Obtención de todas las métricas almacenadas para un sensor en concreto\n\nAccediendo a la URL [https://sensorsapi-mdelapenya.wedeploy.io/sensors/:sensorId](https://sensorsapi-mdelapenya.wedeploy.io/sensors/:sensorId), donde `:sensorId`\nrepresenta el identificador de sensor de interés, la aplicación del API responderá a la petición con\nel resultado de consultar al almacenamiento persistente filtrando por la columna `sensorId`, de modo\nque devolverá todas las métricas almacenadas para el sensor especificado como parámetro. La respuesta\nde la petición estará en formato JSON.\n\n![Resultados al filtrar por un sensor](static/screenshot_api_results.png)\n\nSi no hubiese ninguna métrica almacenada para dicho identificador, lo que indica que el sensor no\nexiste en la plataforma, un mensaje de error 404 de HTTP será retornado en la respuesta.\n\n![Resultados al filtrar por un sensor](static/screenshot_api_404.png)\n\n#### Interfaz de Usuario\n\nAccediendo a la URL https://sensorsui-mdelapenya.wedeploy.io se mostrará el interfaz de usuario que\nmostrará las métricas almacenadas en la plataforma. Nada más acceder a la aplicación, se cargarán\ntodas las métricas disponibles, en un formato tabular.\n\n![Interfaz de usuario: tabla de métricas](static/screenshot_ui_grid.png)\n\nAl lado del botón de buscar, a la derecha, se encuentran dos iconos. Uno de ellos representando un\ngrid, y otro un pin. Seleccionando el icono de grid se mostrará el formato tabular antes mencionado,\nmientras que seleccionando el icono de pin se mostrarán todas las métricas en un mapa.\n\n![Interfaz de usuario: mapa de métricas](static/screenshot_ui_map.png)\n\nEste mapa aparecerá centrado en función a todas las métricas almacenadas, en el centro geométrico de\ntodas ellas. Cada métrica será representada por un `pin` rojo, que al ser clicado mostrará en una\nventana emergente la información de la métrica.\n\n![Interfaz de usuario: detalle de métrica](static/screenshot_ui_metric.png)\n\nSi utilizamos la caja de búsqueda, introduciendo un identificador de sensor que no exista, y pulsamos\nel botón de buscar, se mostrará un mensaje de información indicando que no existen métricas para el\nsensor seleccionado.\n\n![Interfaz de usuario: sensor no encontrado](static/screenshot_ui_empty.png)\n\n## Instalación de la aplicación\n\n### Aplicación Android\n\nPara instalar la aplicación Android, será necesario seguir el siguiente tutorial:\n\n[Manual de instalación de la aplicación Android](https://github.com/mdelapenya/uned-sensors#instalación-de-la-aplicación)\n\n### Plataforma IoT\n\nLa plataforma se encuentra desplegada actualmente en **WeDeploy**, por tanto no es necesario instalarla\nde manera local.\n\n## Integración con otros sistemas\n\nCualquier dispositivo que quiera almacenar sus métricas en la plataforma, únicamente tendrá que enviar\npeticiones `HTTP POST` a la misma, siguiendo la especificación definida por el API REST.\n\nPor ejemplo, una simple petición `curl` sería suficiente para enviar una métrica, siempre y cuando se\nenvíen los datos adecuados en formato JSON:\n\n```shell\ncurl -v -H \"Content-Type: application/json\" -X POST -d '{\"sensorId\":\"abcdefghijk\",\"applicationId\":\"sensors-curl\",\"latitude\":\"40.98765\",\"longitude\":\"-1.12345\",\"metric\":\"24\", \"metricUnits\":\"Celsius\",\"metricName\":\"temperature\",\"timestamp\":\"1489055420416\"}' https://sensorsapi-mdelapenya.wedeploy.io/sensors\n```\n\nPor tanto, para enviar una métrica será necesario por tanto enviar una cabecera indicando que el\n`Content-type` a utilizar durante el intercambio de datos será *JSON*, el verbo HTTP a utilizar será\n*POST*, y la URL que recibirá la petición será la definida por el recurso `/sensors` en la plataforma\n`https://sensorsapi-mdelapenya.wedeploy.io`. En lo que a los datos se refiere, es necesario enviar:\n\n* el identificador del sensor\n* el identificador de la aplicación\n* las coordenadas en formato latitud y longitud\n* el valor de la métrica\n* las unidades de la métrica\n* el nombre de la métrica\n* una marca de tiempo de la petición\n\n## Recursos\n\nSpring Boot: https://spring.io/guides/gs/actuator-service\nSpring Boot, construyendo servicios REST: https://spring.io/guides/tutorials/bookmarks/#_building_a_rest_service\nSpring Boot, sirviendo contenido web: https://spring.io/guides/gs/serving-web-content\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmdelapenya%2Funed-sensors-wedeploy","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fmdelapenya%2Funed-sensors-wedeploy","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fmdelapenya%2Funed-sensors-wedeploy/lists"}