Utilice la API REST para acceder a

ThingWorx
Aproveche la API REST para crear objetos, modificar propiedades,
ejecutar servicios y mucho más.

GUÍA DE CONCEPTO
Este proyecto le introducirá a la API REST utilizada por la plataforma
ThingWorx.

Siguiendo los pasos de esta guía, usted será capaz de conectarse a la

plataforma ThingWorx y hacer llamadas REST para llamar a Servicios,
actualizar Propiedades, y realizar una serie de acciones para sus
aplicaciones IoT.

Le enseñaremos a utilizar la API REST de ThingWorx para crear una

aplicación más robusta. Con la API REST puede aprovechar toda la potencia
del servidor de la Fundación ThingWorx con simples peticiones HTTP. La
API REST puede ser fácilmente explorada usando una herramienta de línea
de comandos como curl, un plugin de navegador como Postman, o
cualquier lenguaje de programación preferido.
APRENDERÁS A
● Crear nuevos objetos en un servidor ThingWorx
Foundation
● Agregar propiedades a los objetos
● Acceder a los valores de las propiedades
● Ejecutar Servicios personalizados
 Índice

● Paso 1: Diseño de la API REST

● Paso 2: Cliente REST
● Paso 3: Crear la clave de la aplicación
● Paso 4: Crear una nueva Thing
● Paso 5: Añadir propiedad a la Thing
● Paso 6: Establecer el valor de la propiedad
● Paso 7: Obtener el último valor de la propiedad
● Paso 8: Llamar al Servicio Personalizado
● Paso 9: Solución de problemas
● Paso 10: Próximos pasos
Paso 1: Diseño de la API REST
Casi todas las Entidades y Servicios de ThingWorx pueden ser accedidos a
través de la API REST. Este paso revisará algunos puntos que son comunes a
todas las llamadas de la API REST de ThingWorx.

La API REST de ThingWorx es la forma de implementar los servicios web en

ThingWorx. Que significa que está sujeta a las limitaciones de los servicios web que
ya discutimos, principalmente que la comunicación es ineficiente y debe ser
iniciada por el dispositivo.

Thingworx API REST

Casi todo lo que se puede hacer en ThingWorx Composer se puede hacer utilizando
la API REST. De hecho, ThingWorx Composer es un cliente ThingWorx basado en la
API REST. Como todos los servicios web, se basa en HTTP o HTTPS. Cualquier
dispositivo que pueda lanzar una URL a Internet puede utilizar la API Rest.

API REST y protocolo de seguridad

Entonces, ¿por qué estamos haciendo una inmersión profunda en la API REST
cuando no lo hacemos para las otras tecnologías de conectividad?
Es porque REST es fundamental para la conectividad de ThingWorx. Es la forma de
comunicarse con ThingWorx. Incluso el protocolo preferido, AlwaysOn, utiliza REST
entre bastidores. Lo que hace AlwaysOn es traducir una petición web en formato
binario y enviarla a través de un WebSocket.
Método API REST
Cada URL tiene un verbo o un método. Cuando escribes una dirección en Google
Chrome, estás ejecutando una solicitud con el método GET. Cuando rellenas un
formulario web, envías una petición POST. Estos métodos forman parte de cómo
funcionan las solicitudes HTTP y HTTPS.

La API REST de ThingWorx utiliza los siguientes cuatro métodos:

● El método GET se utiliza para recuperar información, como propiedades de

ThingWorx.
● El método POST ejecuta servicios de ThingWorx.
● Los métodos PUT y DELETE se pueden utilizar para crear o eliminar de
ThingWorx, pero no los utilizamos con frecuencia. pero no los utilizamos con
frecuencia. Generalmente es una mejor práctica utilizar una solicitud POST y
ejecutar un servicio que cree o elimine elementos de ThingWorx.
● Existen otros verbos, como PATCH y COPY, pero la API REST de ThingWorx
no los utiliza.
Cabecera HTTP para API REST
Las solicitudes web también tienen una cabecera. Esta cabecera contiene pares
nombre/valor enviados al servidor para interpretar el mensaje.

En ThingWorx, los siguientes son tres encabezados que son críticos para las
solicitudes de la API REST:

● AppKey contiene el ID de la clave que autentifica la solicitud. Sin una appKey

válida y los permisos adecuados la solicitud será denegada.
● Content-Type es el formato de los datos que se envían al servidor. Cuando se
trabaja con ThingWorx, esto es siempre JSON.
● Accept le dice a ThingWorx cómo formatear la respuesta. Por lo general,
usted querrá su respuesta en formato JSON. Usted También puede recibir su
respuesta en formato XML o HTML,

Formato JSON
El cuerpo de las peticiones contiene cualquier parámetro de entrada que el servicio
que está ejecutando requiera. Estos parámetros deben enviarse en formato JSON.

En el ejemplo, el servicio CreateThing espera los siguientes tres parámetros de

entrada: el nombre de la Thing, su descripción, y su plantilla base Thing. Nuestro
agente de la API REST debe enviar esos tres parámetros en formato JSON.
URL base
Si navega a /ThingWorx/Server o http://localhost:8080/Thingworx/Server en su
navegador web, podrá navegar por la API REST de ThingWorx. Inicialmente, verá
una lista de tipos de entidades y podrá profundizar para ver las entidades de ese
tipo y sus detalles. Los permisos son obligatorios. No verá entidades o detalles de
entidades a los que no tenga acceso.

Tipo de Entidad
/Server es una URL de inicio especial. Si la URL no tiene un servidor, debe ser un
tipo de entidad, como Things, Thing Templates, Application Keys, Resources o Users.
El servidor devolverá una lista de todas las entidades de ese tipo que tienes acceso
a ver.
Nombre de la entidad
Después de especificar el tipo de entidad, puede especificar la entidad concreta.
Este recuperará detalles sobre esa entidad hasta las características específicas de
esa entidad, como las definiciones de propiedades y las definiciones de servicio.

Tipo de característica
La siguiente parte de la URL es el tipo de característica. Se trata de clasificaciones
de capacidades para la entidad, como propiedades o servicios.

En este nivel, no todo es navegable. Dado que usted está utilizando un navegador
web, cada solicitud que envía a ThingWorx es una petición GET, peticiones Get para
recuperar información y así poder ver las definiciones de los servicios.

Sin embargo, para ejecutar un servicio, es necesario hacer una petición POST.
Cuando intentamos acceder a un servicio directamente utilizando una solicitud GET,
el servidor responde que el método GET no puede acceder a esta funcionalidad.
Nombre del tipo de característica
La última parte de la URL accede a la característica específica por su nombre. Este
puede ser una propiedad, un servicio, un evento o otra capacidad con nombre.

Respuesta a la llamada REST API

El servidor responde a una solicitud con un código de estado. Si la solicitud fue
exitosa, el código de estado es 200 OK. Si recibe cualquier otro código de estado,
indica que la solicitud ha fallado y revisando el código puede explicar por qué ha
fallado.

El servidor también puede responder con un cuerpo, que es la respuesta codificada

en el formato que usted pidió en la cabecera Accept. Sin embargo, es común que el
servidor responda con un estado 200 OK y sin cuerpo. Cuando se ejecutan servicios
sin cuerpo, devuelven 200 OK para indicar que la solicitud fue exitosa y no dan
ninguna información adicional.

Herramientas de prueba para llamadas REST API

Las herramientas de prueba de la API REST de terceros son útiles para la creación
de prototipos y la resolución de problemas de sus solicitudes REST de ThingWorx.
Su navegador web está pensado para recuperar páginas web, no para hacer
llamadas a la API REST, y como resultado, no es muy bueno al respecto. Por
ejemplo, Chrome siempre envía una solicitud GET cuando se visita un sitio, aunque
muchas APIs REST utilizan otros métodos.
Una buena herramienta como Postman o Insomnia te permitirá configurar tu
petición de forma muy específica, incluyendo el método, la cabecera, el cuerpo y la
información de autenticación. Obtiene la respuesta completa del servidor,
incluyendo cualquier código JSON, XML o HTML.

Por último, después de realizar una petición, puede recuperar un código de

programación de copiar y pegar para implementar esa solicitud en su agente en
varios lenguajes de programación.

Utilizaremos el software Postman en nuestros ejercicios de la API REST.

Sintaxis de la API REST

Los URLs de los puntos finales utilizados por la API REST siguen el patrón
consistente que se muestra en el siguiente diagrama.
La siguiente tabla describe las piezas individuales de la URL para las
llamadas a la API REST.
Term Description Optional/Required?

http method GET, PUT, DELETE, POST required

scheme http, https required

host server IP address where required

ThingWorx is running

port port on which the Web optional

Server is listening for
requests (default is 80)

entity collection One of the built-in entity required

collection types proprietary
to ThingWorx

entity name that identifies a required

specific characteristic

characteristic collection Names such as Property optional

Definition, Properties VTQ,
ThingName, and Service
Definition

characteristic name of the Service or optional

Property on which to
execute

accept header format of HTTP content optional

being requested; must be
application/json or
 text/xml or text/html

content type header format of HTTP content required

being provided; must be
application/json, text/csv
or text/html

content optional

query parameters optional

Solicitudes
La API REST de ThingWorx utiliza verbos de solicitud HTTP de forma común a
muchas API REST:

● GET para recuperar información

● POST para crear una nueva entidad y ejecutar un servicio
● DELETE para eliminar un objeto o propiedad
● PUT para cambiar el valor de una entidad existente
Cuando una solicitud de la API REST requiere el envío de parámetros, la cabecera
Content-Type debe ajustarse al formato del cuerpo de la solicitud.

Para descubrir y utilizar los servicios es necesario utilizar una URL específica. Para
listar los servicios disponibles y ver sus definiciones, emita un GET a
<servidor_ip:puerto>/Thingworx/Things/<nombre de la Thing>/ServiceDefinitions

Para ejecutar un servicio de la lista, envíe un POST a

<servidor_ip:puerto>/Thingworx/Things/<nombre de la
Thing>/Services/<nombre del servicio>

NOTA: La cabecera Content-Type de un POST que ejecuta un Servicio debe

ser siempre application/json o text/xml incluso si el servicio no toma ningún
parámetro y no se envía ningún contenido.
Cabeceras
Las siguientes tablas describen los valores válidos de las cabeceras Accept y
Content-Type al realizar una llamada a la API REST.

Accept headers
Si la solicitud envía una cabecera Accept no válida, o no se suministra ninguna
cabecera Accept, la respuesta por defecto será en formato text/html.
Value Syntax

JSON application/json

XML text/xml

HTML text/html (or omit Accept header)

CSV text/csv

Content type headers

Se requiere una cabecera Content-Type que indique el formato de los datos
enviados a ThingWorx. Algunas solicitudes POST requieren una cabecera de tipo de
contenido incluso cuando no se envían datos.

Value Syntax

JSON application/json

XML text/xml
Paso 2: Cliente REST
Para realizar llamadas a cualquier API REST se necesita un software cliente. Se
puede utilizar un navegador web para hacer algunas llamadas GET, pero hay que
instalar extensiones para modificar las cabeceras o para hacer llamadas POST o
PUT.

Las opciones de software cliente incluyen:

● cURL es una venerable herramienta de línea de comandos y una biblioteca

que es una navaja suiza para tratar las peticiones web. Y como una vieja
navaja suiza, puedes hacer que funcione, pero puedes acabar haciéndote
daño.
● Httpie es una moderna herramienta de línea de comandos con opciones
fáciles de usar e intuitivas. Las respuestas del servidor se muestran en color
con un formato fácil de leer. Los ejemplos se darán como comandos HTTPie.
● Postman es una plataforma de API para crear y utilizar APIs. Postman
simplifica cada paso del ciclo de vida de la API y agiliza la colaboración para
que puedas crear mejores APIs, más rápido.

Instalación de Postman
1.- Descarga e instale el software gratuito desde la página web
https://www.postman.com/downloads/
2.- Cree una cuenta Postman e ingrese.
Finalizado el paso anterior puede escoger programar la aplicación API desde el
navegador o desde el software de escritorio.

Paso 3: Crear una Clave de Aplicación

En este Quickstart, usted utilizará ThingWorx Composer para generar una Clave de
Aplicación.

Un dispositivo debe ser autentificado para enviar o recibir datos de ThingWorx. Uno
de los métodos de autenticación más comunes utilizados con ThingWorx es el uso
de un token de seguridad llamado Application Key o appKey. Estos tokens están
asociados a un usuario en particular y tienen los mismos permisos que ese usuario.

Crear una Clave de Aplicación

1.- En la pantalla de inicio de Composer haz clic en + Nuevo.
2.- En la lista desplegable, haga clic en Clave de aplicación.
3.- Asigne un nombre a su clave de aplicación (por ejemplo, PostmanAppKey_XX).
4.- Establezca la referencia de nombre de usuario a un usuario que haya creado.

5.- Actualice el campo Fecha de caducidad, de lo contrario será por defecto de 1

día.
6.- Haga clic en Guardar. Se ha generado un ID de clave y puede utilizarse para
realizar conexiones seguras.

MEJOR PRÁCTICA: Le recomendamos que cree claves separadas para cada

dispositivo, usuario o sistema conectado. Esto permite una mejor seguridad en caso
de situaciones en las que pueda necesitar revocar el acceso de uno de ellos.

Paso 4: Crear un nuevo Thing

Un Thing es un bloque de construcción básico utilizado para modelar aplicaciones
en el ThingWorx Foundation Server. Todos los objetos se basan en una plantilla de
objeto, ya sea una plantilla del sistema incorporada o una plantilla personalizada
creada previamente. Con la API REST, se pueden crear, modificar, listar y eliminar
Things. Después de que se haya creado un Thing mediante una llamada a la API,
debe ser habilitado y reiniciado con llamadas adicionales a la API antes de que
pueda ser utilizado.

Parámetros necesarios
● AppKey creada por su servidor ThingWorx
● Un nombre para el nuevo Thing
● El nombre de un ThingTemplate válido que se utilizará para crear el nuevo
Thing

Solicitud
Una solicitud HTTP POST a ThingWorx se ensambla a partir de 3 componentes:
● una URL
● Un cuerpo POST
● Credenciales de autenticación.
Una solicitud a ThingWorx puede realizarse sólo después de que estos 3
componentes estén correctamente configurados.

1.- Navega hasta http://localhost:8080/Thingworx/Server en tu navegador web.

2.- Haz clic en Resources>EntityServices>Services Definitions. Podrás ver una
lista de los servicios disponibles para ser utilizados. En este caso usaremos el
servicio CreateThing.
3.- Haz clic en el servicio CreateThing.
4.- Examina la definición de parámetros de este servicio.

Construir la URL.
1.- Cree un nuevo Thing haciendo un HTTP POST al endpoint
<server_ip:port>/Thingworx/Resources/EntityServices/Services/CreateThing
Ej:
http://10.10.200.200:8080/Thingworx/Resources/EntityServices/Services/CreateThing

NOTA: El server_ip es la dirección ip de su servidor ThingWorx Core.

2.- Parámetros requeridos del cuerpo de POST.

Envíe el nombre del Thing y el nombre del ThingTemplate que definirá el nuevo
thing en el cuerpo del POST como un objeto JSON. Por ejemplo, el objeto JSON de
abajo creará una nueva Thing llamada APIThing_XX usando la plantilla del sistema
GenericThing. Selecciona POST y en la casilla de la izquierda pega la url que
construimos en el paso anterior. Selecciona Body para agregar el contenido de la
llamada API REST y verifica que tenga formato raw y JSON.

{
"name": "APIThing_XX",
"thingTemplateName": "GenericThing"
}
SUGERENCIA: Al crear Things que se utilizarán con la API REST, utilice el
GenericThing ThingTemplate o un GenericThing basado en ThingTemplate.
Un RemoteThing sólo debe usarse con dispositivos que hacen una conexión
AlwaysOn™ a un servidor ThingWorx usando el Edge MicroServer o uno de los
SDKs AlwaysOn™.

3.- Cabeceras (Headers)

Todas las solicitudes de la API al servidor ThingWorx deben ser autenticadas con
una appKey. Además debemos indicar el tipo de contenido del cuerpo del mensaje
(Content-Type) y los formatos de respuestas que aceptará Postman.
Key Value

appKey <PostmanAppKey_XX ID>

Content-Type application/json

Accept text/csv
4.- Respuesta
Una llamada exitosa al servicio CreateThing no devuelve ningún contenido en el
cuerpo de la respuesta, sólo se devuelve un HTTP 200. Para verificar que la Thing
fue creada correctamente navega en Thingworx Composer>Browse>Thing. Si el
status en Postman es 200 OK deberías tener ver en la lista de Thing a
APIThing_XX.

Validar
El Thing que acaba de crear está ahora disponible en el Compositor de ThingWorx,
sin embargo, antes de que se pueda hacer algo más con su nuevo Thing a través de
la API REST, debe ser habilitado e iniciado. Siga estos pasos para validar que el
nuevo Thing ha sido creado y habilitado.

1.- En la página de inicio de Composer, haz clic en Things, selecciona el nombre del
Thing que acabas de crear y luego haz clic en General Information.
 NOTA: Verá que la casilla Activo no está marcada, lo que indica que esta
Thing no está habilitada.

2.- Ejecute el servicio EnableThing.

Para habilitar su Thing recién creada, haga un POST HTTP al punto final de abajo.
Sustituya <nombre de la Thing> por el nombre real de la Thing que ha creado. No se
requiere ningún cuerpo en el POST, sin embargo, la cabecera Content-Type de un
POST que ejecuta un Servicio debe ser siempre application/json o text/xml incluso
si el servicio no toma ningún parámetro y no se envía ningún contenido. No se
devuelve ningún cuerpo en caso de éxito, sólo un código de respuesta HTTP 200.
Para simplificar el proceso duplique la pestaña creada en el paso anterior, borre el
contenido de Body y sustituya la url por la siguiente:
<servidor_ip:puerto>/Thingworx/Things/<nombre de la Thing>/Services/EnableThing

Obtendrá lo siguiente:

3.- Confirme que la nueva Thing está habilitada.

Para actualizar la sección de Información General de su nueva Thing y confirmar
que la casilla Activa está ahora marcada, actualice la página con el navegador o
cierre y vuelva a abrir su Thing.
4.- Reinicie su Thing.
Después de la creación de un Thing y cada vez que se realicen cambios en su
estructura, el Thing debe ser reiniciado. Inicie su nueva Thing haciendo un POST
HTTP al punto final de abajo. Sustituya <nombre de la Thing> por el nombre real de
la Thing que ha creado. No se requiere ningún cuerpo en el POST, sin embargo, la
cabecera Content-Type de un POST que ejecuta un Servicio debe ser siempre
application/json o text/xml incluso si el servicio no toma ningún parámetro y no se
envía ningún contenido. No se devuelve ningún cuerpo en caso de éxito, sólo un
código de respuesta HTTP 200. Duplique la pestaña creada en el paso anterior y
sustituya la url por la siguiente:
<servidor_ip:puerto>/Thingworx/Things/<nombre de la Thing>/Services/RestartThing

Obtendrá lo siguiente:
Paso 5: Añadir una propiedad a un
objeto
Los valores de las propiedades se asocian a una thing específica, y se utilizan para
almacenar datos que cambian con el tiempo.

Parámetros requeridos:
● AppKey creada por su servidor ThingWorx
● Nombre de la thing a la que se añadirá la propiedad
● Nombre de la nueva Propiedad y tipo de datos del valor de la Propiedad

Solicitud
1.- Construya la URL.
Se puede añadir una nueva propiedad a un objeto existente haciendo un POST
HTTP a este punto final. Sustituya <nombre de la Thing> por el nombre real de la
Thing que existe en el servidor de ThingWorx a la que se añadirá la propiedad.
Duplique la pestaña creada en el paso anterior y sustituya la url por la siguiente:
<server_ip:port>/Thingworx/Things/<name of Thing>/Services/AddPropertyDefinition

Al duplicar la pestaña no tendrá que ingresar nuevamente las cabeceras.

2.- Parámetros de la petición de envío.

El nombre de la nueva Propiedad a añadir y el tipo de la Propiedad se envían en el
cuerpo del POST como un objeto JSON. Por ejemplo, el objeto JSON de abajo creará
una nueva Propiedad llamada SomeNumber usando el tipo base de ThingWorx
NUMBER. Otros tipos comúnmente utilizados son STRING, INTEGER y BOOLEAN.

{
"name" : "SomeNumber",
"type" : "NUMBER"
}
Respuesta
Una llamada exitosa al servicio AddPropertyDefinitions no devuelve ningún
contenido en el cuerpo de la respuesta. Sólo se devuelve un HTTP 200.
Obtendrá lo siguiente.

Validar
1.- Ver nueva propiedad en el servidor.
La propiedad que acaba de añadir está ahora disponible en el ThingWorx Composer.
Antes de que se pueda hacer algo más con su nueva Propiedad a través de la API
REST, el Thing debe ser reiniciado. Para confirmar que su Propiedad fue agregada a
su Thing, abra Composer y haga clic en Things, seleccione el nombre de la Thing
que acaba de crear, luego haga clic en Propiedades y Alertas. Verá la nueva
propiedad en la lista. Es posible que tenga que actualizar para ver los cambios.

2.- Ejecute el servicio RestartThing.

Reinicie su Thing con la Propiedad añadida haciendo un POST HTTP al endpoint de
abajo. Sustituya <nombre de la Thing> por el nombre real de la Thing que ha
creado. No se requiere ningún cuerpo en el POST, sin embargo, la cabecera
Content-Type de un POST que ejecuta un Servicio debe ser siempre
application/json o text/xml incluso si el servicio no toma ningún parámetro y no se
envía ningún contenido. No se devuelve ningún cuerpo en caso de éxito, sólo un
código de respuesta HTTP 200.

<server_ip:port>/Thingworx/Things/<name of Thing>/Services/RestartThing

Paso 6: Establecer el valor de la

propiedad
Puede establecer el valor de una propiedad específica con la API REST utilizando el
verbo PUT.

Parámetros requeridos:
● AppKey creada por su servidor de Foundation
● Nombre de la Thing válida y nombre de la Propiedad
● Nuevo valor de la propiedad

Solicitud
1.- Construya la URL.
Un valor de Propiedad puede ser establecido haciendo una llamada HTTP PUT a
este endpoint:
<server_ip:port>/Thingworx/Things/<name of Thing>/Properties/<name of
Property>

Sustituya <nombre de la Thing> por el nombre real de una Thing que existe en el
servidor ThingWorx y <nombre de la Propiedad> por el nombre de una Propiedad
que se ha añadido a la Thing.

2.- Envíe los parámetros de la solicitud.

El nombre de la propiedad a establecer se duplica en el cuerpo del PUT y se envía
junto con el valor como un objeto JSON. El ejemplo siguiente establecerá la
propiedad SomeNumber a 34.4
 {
"SomeNumber" : 34.4
}

Respuesta
Una llamada exitosa para establecer una propiedad no devuelve ningún contenido
en el cuerpo de la respuesta. Sólo se devuelve un HTTP 200.

Validar
Para confirmar que la propiedad fue cambiada para su Thing, vaya a Composer y
haga clic en Things. Seleccione el nombre de la Thing que acaba de crear y haga clic
en la pestaña Propiedades y Alertas. Haz clic en la flecha circular Actualizar para ver
el valor de la propiedad actualizada.
Paso 7: Obtener el último valor de la
propiedad
Puede recuperar los valores de las propiedades de una Thing específica con la API
REST utilizando el verbo GET.

Parámetros requeridos:
● AppKey creada por su servidor ThingWorx
● Nombre de la Thing y nombre de la propiedad

Solicitud
1.- Construya la URL.
Para obtener el valor actual de una propiedad, haga una petición GET a este
endpoint:

<server_ip:port>/Thingworx/Things/<name of Thing>/Properties/<name of
property>

Sustituya <nombre de la Thing> por el nombre real de una Thing que existe en el
servidor ThingWorx y <nombre de la Propiedad> por el nombre de una Propiedad
que se ha añadido a la Thing.

NOTA: La solicitud completa también deberá incluir el nombre de host y las

credenciales de autenticación de su servidor ThingWorx específico.

2.- Envíe los parámetros de la solicitud. Aparte de la autenticación, no se utilizan

otros parámetros en esta solicitud GET.

Respuesta
El contenido puede ser devuelto en cuatro formatos diferentes enviando una
cabecera Accept con la solicitud.
 Desired Response Type Accept Header Values

JSON application/json

XML text/xml

HTML text/html (or omit Accept Header)

CSV text/csv

Obtendrá lo siguiente:
Paso 8: Llamar a un servicio
personalizado
Para ejecutar un Servicio de una Thing específica con la API REST, puede utilizar el
verbo POST.

Parámetros requeridos:
● AppKey creada por su servidor ThingWorx
● Nombre de la Thing que implementa un Servicio personalizado
● Nombre del Servicio personalizado
● Nombres de las entradas, si las hay, requeridas por el Servicio

Crear Servicio
Desafio: Cree un servicio que entregue como resultado la suma de dos números y
que cambie el valor a 10 de la propiedad antes creada.
Ayuda:

Solicitud
1.- Construya la URL.
Para llamar a un Servicio personalizado de una Thing existente, haga un POST HTTP
a este punto final:

<server_ip:port>/Thingworx/Things/<name of Thing>/Services/<name of
Service>

Sustituya <nombre de la Thing> por el nombre real de una Thing que exista en el
servidor ThingWorx, y <nombre del Servicio> por un Servicio existente.

2.- Parámetros de la solicitud de envío

Los nombres de las entradas junto con sus valores se envían en el cuerpo del POST
como un objeto JSON. Por ejemplo, el objeto JSON de abajo enviará un parámetro
llamado 'firstNumber' con un valor de 35 y un parámetro llamado secondNumber
con un valor de 711.

{
"firstNumber": "35",
"secondNumber": "711"
}

NOTA: La solicitud completa debe incluir una cabecera con la appKey de su

servidor ThingWorx específico.
Respuesta
Una llamada exitosa a un Servicio devolverá un objeto JSON en el cuerpo de la
respuesta que contiene un objeto llamado resultado con el valor devuelto por el
Servicio personalizado. Este es un ejemplo de respuesta:

{
"result": 746.0
}

ADVERTENCIA para otros clientes HTTP: La mayoría de los clientes HTTP no

establecen una cabecera Content-Type por defecto, sin esta cabecera
establecida el servidor devolverá un mensaje de error. La solicitud POST al
punto final del servicio tiene un cuerpo JSON, por lo que la cabecera debe
establecerse para que coincida con el formato del cuerpo de la solicitud.

Paso 9: Solución de problemas

Debería esperar que le devolvieran el código de estado 200 - OK con o sin
contenido. En el caso de un error, recibirá un mensaje de error. Puede utilizar la
siguiente tabla para diagnosticar el problema.
Response Code Definition

401 - Unauthorized appKey is incorrect or missing

403 - Forbidden Content-Type request header is not set to

application/json

Sometimes returned instead of a 404

A Property with that name already exists on

the platform

404 - Not Found Incorrect URL or API endpoint

Thing or Property has not been created

Incorrect ThingTemplate name

Required parameter missing from request

405 - Invalid Request Incorrect request verb; for example a GET

was used instead of PUT or POST

406 - Not Acceptable Invalid JSON in PUT or POST request

Thing [ Thing name ] already exists: A Thing

with that name already exists on the platform

500 - Internal Server Error Content-Type request header is not set for a
service execution POST, required even
without a POST body

Content-Type request header is not set for

DELETE request, required despite the fact
that DELETE does not send any content
 503 - Service Unavailable Thing [] is not running

RestartThing endpoint must be called

Thing [] is not enabled

EnableThing endpoint must be called

Paso 10: Resumen

Enhorabuena. Ha completado con éxito la guía Uso de la API REST para acceder a
ThingWorx.

Ha aprendido a utilizar la API REST para:

● Crear nuevos objetos en un servidor ThingWorx Foundation
● Agregar propiedades a los objetos
● Acceder a los valores de las propiedades
● Ejecutar Servicios personalizados