CREA developer Portal

Welcome to the CREA developers portal


Getting Started

We recommend the following resources before getting started with this guide.

WHAT IS REST?

REST is the underlying architectural principle of the web. The amazing thing about the web is the fact that clients (browsers) and servers can interact in complex ways without the client knowing anything beforehand about the server and the resources it hosts. The key constraint is that the server and client must both agree on the media used, which in the case of the web is HTML.

An API that adheres to the principles of REST does not require the client to know anything about the structure of the API. Rather, the server needs to provide whatever information the client needs to interact with the service. An HTML form is an example of this: The server specifies the location of the resource, and the required fields. The browser doesn't know in advance where to submit the information, and it doesn't know in advance what information to submit. Both forms of information are entirely supplied by the server. (This principle is called HATEOAS.)

So, how does this apply to HTTP, and how can it be implemented in practice? HTTP is oriented around verbs and resources. The two verbs in mainstream usage are GET and POST, which I think everyone will recognize. However, the HTTP standard defines several others such as PUT and DELETE. These verbs are then applied to resources, according to the instructions provided by the server.

For example, Let's imagine that we have a user database that is managed by a web service. Our service uses a custom hypermedia based on JSON, for which we assign the mimetype application/json+userdb (There might also be an application/xml+userdb and application/whatever+userdb - many media types may be supported). The client and the server has both been programmed to understand this format, but they don't know anything about each other. As Roy Fielding points out:

A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types.

CREA API


Here you will find the CREA API calls documentation. This is a REST API, so you can take that in count.

Good luck creating.


session

This section is the one in charge of managing the API login and token generation

POST v1/session

Generates a new token, the token is obtained from the base64 encoding from the API key and the API secret pairing (as a Basic http authentication). This is obtained from the seciont "API Access" from the dashboard.

Authentication: BASIC

scopes
REQUEST
Si
string (default: module-owner)


module

This section is the one in charge of managing the user associated modules

GET v1/module

Returns the list of all the token associated modules

Authentication: BEARER


GET vi/module/:id

Returns the information of an specific module

Authentication: BEARER

id
URL
Si
MD5

GET v1/module/:id/actions

Returns the actions associated to the module

Authentication: BEARER

id
URL
Si
MD5

POST v1/module

Creates a new module

Authentication: BEARER

nombre
REQUEST
Si
string
tipo
REQUEST
Si
integer

PUT v1/module/:id/register-action

Creates a new action associated to the module :id

Authentication: BEARER

id
URL
Si
MD5
comando
REQUEST
Si
string
tipo-accion
REQUEST
Si
integer
input
REQUEST
Si
integer

PUT v1/module/:id/execute-action

Executes a new action associated to the module :id

Authentication: BEARER

id
URL
Si
MD5
value
REQUEST
Si
string
action
REQUEST
Si
integer

PUT v1/module/:id/request-status

Requests the information related to the module

Authentication: BEARER

id
URL
Si
MD5

PUT v1/module/:id/disable

Deactivates the module for been used

Authentication: BEARER

id
URL
Si
MD5

PUT v1/module/:id/enable

Activates the module previously deactivated

Authentication: BEARER

id
URL
Si
MD5

DELETE v1/module/:id

Elimina el modulo id

Authentication: BEARER

id
URL
Si
MD5

DELETE v1/module/:id/actions

Deletes the action related to the module :id

Authentication: BEARER

id
URL
Si
MD5
action
REQUEST
Si
integer


user

This section is in charge of manage the user accounts

GET vi/user/:id

Returns the information of a User. Only can be retrieved the user related to the token

Authentication: BEARER

id
URL
Si
string

GET vi/user/:id/api

Returns the API access information related to the user

Authentication: BEARER

id
URL
Si
string

PUT v1/module/:id/update

Updates the user information

Authentication: BEARER

id
URL
Si
string
nombre
REQUEST
Si
string
apellido
REQUEST
Si
string
email
REQUEST
Si
string
password
REQUEST
Si
string

Developing mobile applications with the CREA API


The following guide takes you to understand how to develop applications using the CREA API in an Android device

Good luck creating.

Getting Started

We recommend the following resources before getting started with this guide.

Interaction with the CREA websocket


In this section we will explain how the CREA API interacts with the websocket and allows devices to interact with the API

Getting Started

You can test the websocket here


Commands

Commands are executed during the WebSocket connection with CREA after the handshake

CRAUTH

Authenticates with the CREA user associated to the token


authentication
Base 64 encryption from API Key and API Secret
Si
CRAUTH|[authentication]
ACK

SUBSCR

Subscribe the module to the websocket connection.


module
MD5
Si
SUBSCR|[module]
ACK

GET

Solicita mensajes del lado del servidor



SEND

Envia un mensaje al servidor


action_id, message
string
Si
SEND|[action_id]|[message]
ACK