> For the complete documentation index, see [llms.txt](https://doc.velneo.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.velneo.com/velneo-verp/documentacion-del-apirest.md). # ApiRest de vERP ## ¿Qués es la API Rest de Velneo vERP? Todas las aplicaciones programadas con la plataforma de desarrollo Velneo, simplemente heredando vERP y sin necesidad de programar, pueden disponer de una API Rest para consumir sus datos y funcionalidades. La API Rest de Velneo es segura, funciona con protocolo https, permite autenticarse por aplicación (con una API Key), por usuario (con un token Bearer) o con OAuth 2.0, y para cada API puedes configurar qué tablas, búsquedas o procesos estarán disponibles. Incluso para cada tabla puedes indicar qué campos estarán visibles. También permite establecer permisos por usuario. La API Rest de Velneo está autodocumentado a través del servicio estándar Open API permitiendo a terceros usar tu API Rest, ya que está basada en el estándar json:api. Existen tres versiones de la API Rest integradas en la plantilla: **V1**, **V2** y **V3**. **V1** es la versión que se usaba hasta la versión 33, que sigue el estándar Swagger, y que se mantiene por compatibilidad con desarrollos que la sigan usando. **V2** es una versión evolucionada para adaptarse al estándar OpenAPI y es la que se recomienda usar. [**V3**](#v3) es una versión evolucionada y mejorada de V2 la cual permite nuevos métodos disponible (PUT) y permite ejecución interna, entre otras características. Si estás usando V1, te recomendamos que vayas adaptando tus desarrollos a V2 ya que dejará de estar soportado en futuras versiones de la plantilla. ## ¿Puedo usar esta API REST sin heredar o usar Velneo vERP? Para poder usar la API Rest es necesario heredar vERP ya que hace uso de la tabla de usuarios (USR\_M) que está relacionada, directa o indirectamente con un elevado número de tablas de plantilla y requeriría tenerlas todas replicadas en el programa donde se quisiese usar. ## Ejecutar la aplicación y configurar la seguridad La seguridad de la API REST está basada en 2 capas actualmente: * Capa 1: autentificación, con una API key por aplicación, un token Bearer por usuario o OAuth 2.0 por usuario. * Capa 2: configuración de seguridad a nivel de tablas, campos, procesos y búsquedas. La capa 1 se configura desde la opción **API keys** del menú **Supervisor**. Según el tipo de autentificación que elijamos, la API se protege con una clave definible por el programador o el usuario en tiempo de ejecución (por aplicación) o con un token distinto para cada usuario. Al ejecutar esta opción se muestra el formulario de menú de API keys.
Podemos crear tantos registros como queramos. Para crear una nueva API key debemos pulsar el botón + de la barra de herramientas de la rejilla. En cada registro de API key debemos grabar una **descripción**, el **tipo de autentificación** y, si es por aplicación, el **valor** de la clave. En **Tipo de autentificación** indicamos cómo se autentican quienes usan la API: * **Por aplicación**: la clave de la API (campo **API key**) identifica a la aplicación que usa la API. La clave se envía en el parámetro `api_key` de la URL o en la cabecera `X-API-KEY`. La clave tiene además una fecha de caducidad: si los días de caducidad son 0, no caduca (la fecha aparece como 31/12/2100). * **Bearer por usuario**: cada usuario autorizado dispone de su propio token Bearer. Para configurarlo: 1. Crea la API key con este tipo, y habilita los métodos y los objetos que necesite. 2. En la pestaña de configuración, selecciona los grupos de usuarios autorizados a usar la API. 3. En la ficha de cada usuario que vaya a usarla, en la pestaña de API's, pasa la API de la lista **API's no autorizadas** a **API's autorizadas al usuario**. 4. Haz doble clic sobre la API en la lista **API's autorizadas al usuario** y pulsa **Actualizar token**. En ese momento se genera el token Bearer de ese usuario para esa API. El cliente envía el token en la cabecera `Authorization: Bearer `. Las acciones que se realicen con ese token se ejecutan con los permisos de ese usuario. * **oAuth por usuario**: la API implementa el flujo de autorización OAuth 2.0 con código de autorización. La aplicación cliente redirige al usuario a la página de inicio de sesión de la API, donde se identifica con su email y contraseña. Tras autenticarse, la API devuelve a la URI de redirección un código, que la aplicación cambia por un token de acceso y un token de refresco. En la API se configuran las URI de redirección autorizadas (la aplicación cliente debe usar una de ellas), y el **Client ID (oAuth)** y el **Client Secret (oAuth)** se calculan automáticamente. El token de acceso caduca al cabo de aproximadamente una hora, y con el token de refresco se obtiene uno nuevo. Si se activa **Utilizar proveedor externo de oAuth**, la autenticación del usuario la gestiona un proveedor externo. En ese caso hay que indicar el **Client ID (oAuth)** y el **Client Secret (oAuth)** del proveedor, y un **Script de autorización**, un script del proyecto que gestiona la autorización contra ese proveedor. Cuando se autoriza una API a un usuario, aparece en la lista **API's autorizadas al usuario** de su ficha, con su nombre, su token, su último acceso, su caducidad y si está inactiva. Al hacer doble clic sobre ella se abre la ventana **API del usuario**, con dos pestañas. **Datos** * **¿Dónde se usa?**: un texto libre para identificar dónde se utiliza el token. * **Token**: el token del usuario para esa API. En las APIs de tipo Bearer por usuario está vacío hasta que se pulsa **Actualizar token**. * **Control de caducidad de las credenciales**: * **Último cambio de credenciales**: la fecha en que se generó o actualizó el token. * **Días de caducidad de las credenciales**: los días que el token es válido desde el último cambio. Al actualizar el token se rellena con el valor por defecto de la configuración de la aplicación (**Días de caducidad de las credenciales, por defecto**, 180 por defecto). * **Antigüedad de las credenciales**: los días transcurridos desde el último cambio. * **Fecha de caducidad de las credenciales**: el último cambio más los días de caducidad. Pasada esa fecha, el token deja de ser válido y la petición se rechaza. * **Inactivo**: inactiva la autorización de la API para ese usuario. Mientras está inactiva, el token no se acepta. El botón **Actualizar token** pide confirmación y genera un token nuevo para esa API y ese usuario, y reinicia el control de caducidad. El token anterior deja de ser válido. **Logs** Permite consultar los accesos realizados con la API: se indica un rango con **Fecha desde** y **Fecha hasta**, y al pulsar la lupa se listan la fecha, la hora, el usuario y la URL de cada uno. Solo se registran si la API tiene activado el log. En la pestaña **seguridad** de la API key podremos generar tantos registros como tablas tenemos en nuestros proyectos de datos, más un registro para los objetos poder configurar la seguridad de los procesos que no tienen tabla destino declarada. ![](https://content.gitbook.com/content/3LV49PQOXXZc5eok6Vpo/blobs/0DHlq2yow7mJL4xw9SQ0/Recorte%20-%20Mi%20ERP%20-%20Ejemplo,%20S.A%20\(29\).png) En el formulario se puede configurar con el check si es para procesos sin tabla destino, una vez marcado sólo nos aparecerá la pestaña de procesos:
En la parte superior tenemos 4 checks para configurar si este API key soporta los métodos GET, POST y DELETE. En caso de no marcar el check sin tabla nos aparecerán 3 pestañas para configurar la seguridad de campos, procesos y búsquedas.
Para seleccionar un proceso, lo que debemos seleccionar en los combo boxes son el proyecto de datos donde está tabla de destino y la tabla de destino. En el caso de configurar una tabla debemos seleccionar un proyecto de datos de todos los cargados en ejecución y una vez seleccionado el proyecto podremos elegir la tabla sobre la que vamos a configurar la seguridad. De igual modo podemos configurar en la parte superior derecha los métodos aceptados para dicha tabla (GET, POST y DELETE). Las tres pestañas de seguridad de campos procesos y búsquedas tiene la misma funcionalidad y usabilidad. Por defecto la API REST no permitirá devolver información de un campo, proceso o búsqueda que tengan marcado el estilo **privado**. En la de campos tenemos un check que nos permite indicar si queremos que todos los campos de la tabla que no sean privados estén disponibles para el API. Conviene marcarlos si queremos que estén accesibles la mayoría de campos, en ese caso los campos que seleccionemos en la rejilla inferior serán excluidos del retorno de información que genere el API. Los campos que devolverá el JSON al ejecutar el proceso son los que se marquen en la pestaña **campos** del API, que no hay que programar nada en el proceso.
Si queremos dejar accesible un número pequeño de campos es mejor no marcar el check y hacer la selección de los campos accesible. En definitiva lo que se trata es de seleccionar de la lista el menor número de elementos utilizando el check para dicho fin. Los procesos y las búsquedas funcionan igual con un check que permite seleccionar todas excluyendo las seleccionadas o solo incluir las seleccionadas si no marcamos el check.
## Formas de publicar la API REST La API REST de Velneo vERP se puede publicar de dos formas: * [**Servicio https de Velneo vServer**](#publicar-la-api-rest-en-el-servicio-https-de-velneo-vserver): directamente en un [virtual host de vServer](/velneo-vadmin/web.md), sin necesidad de Apache. Es la opción recomendada. * [**Apache con vModApache**](#publicar-la-api-rest-en-apache): instalando el componente [vModApache](/velneo-vmodapache/que-es-velneo-vmodapache.md) en un servidor web Apache. ## Publicar la API REST en el servicio https de Velneo vServer Para publicar la API REST en un virtual host del servicio https de Velneo vServer, [configura una instancia en Velneo vAdmin](/velneo-vadmin/web.md): 1. Abre vAdmin y conéctate al servidor. 2. En el menú lateral, ve a **Web**. 3. Haz doble clic en el virtual host en el que quieras publicarla (por ejemplo, **Puerto https: 443 (TLS/SSL)**) o crea uno nuevo con el botón **Nuevo virtual host**. 4. En la pestaña **Instancias**, pulsa el botón de añadir (+) e indica: * **Ruta**: la dirección de acceso, por ejemplo `/verp-api`. * **Instancia**: la instancia de la aplicación. * **Usuario**: un usuario declarado en el vServer con permisos de acceso a la instancia. 5. Acepta la instancia, acepta el virtual host y aplica los cambios. Una vez publicada, consulta [Probar la API desde Swagger](#probar-el-api-desde-swagger) para comprobar que funciona. ### Publicar la API REST en Apache {% hint style="warning" %} En futuras versiones, vModApache quedará obsoleto. Te recomendamos publicar la API REST en el servicio https de Velneo vServer. {% endhint %} Para acceder a la API REST a través de Apache se usa el componente [vModApache](/velneo-vmodapache/que-es-velneo-vmodapache.md), que permite que el servidor web Apache pueda servir de forma automática la documentación swagger y la API REST de tu aplicación. La instalación lleva mismos pasos que la instalación habitual de [vModApache](/velneo-vmodapache/que-es-velneo-vmodapache.md). Es extremadamente importante que configures el Apache en HTTPS con un certificado. De esta forma evitas que la información http viaje en plano y sea accesible por terceros. #### Configuración del servidor Apache Añadir una directiva location o virtualhost para conectarse a la instancia de la aplicación en el [fichero de configuración de Apache](/velneo-vmodapache/instalacion-y-configuracion-vmodapache.md#configurar-en-apache-las-directivas-de-virtualhost-o-location-para-el-servicio-de-paginas-de-velneo). Ejemplo: ``` setHandler velneo Vrl vatp://pepe:verp1234@c22.velneo.com:7050/VERP ``` #### Reiniciar el Apache Una vez aplicadas las configuraciones, reiniciamos el servidor Apache. ### Probar el API desde Swagger Este apartado es válido tanto si publicas la API REST en el servicio https de Velneo vServer como con Apache. Las URL de la API son las mismas en ambos casos: solo cambia dónde se configura. #### ¿Qué es Swagger? Swagger es estándar para definir interfaces de API REST que permite que tanto personas como máquinas puedan entender y comprender las capacidades de un servicio sin acceder al código fuente o una documentación específica. Actualmente swagger forma parte de la especificación OpenApi. El API REST de Velneo genera dinámicamente un fichero de definición swagger del API disponible en tu aplicación. Para acceder Swagger usa la siguiente url: Verás que al cargar la página propone la url de acceso a la instancia web que tenemos de la demo de Velneo vERP () y nos pide que introduzcamos la APIKey. En el caso de la demo de vERP ésta es: api123 Así ya podrás comprobar cómo funciona. {% hint style="info" %} **Nota:** la URL anterior corresponde a la **V1** del API (que usa el endpoint `swagger`). Si vas a usar la **V2** debemos usar el endpoint `openapi`, por lo que en la url reemplazaremos `swagger` por `openapi`, por ejemplo: `https://demoapi.velneo.com/verp-api/vERP_2_dat_dat/`**`openapi`** {% endhint %} Para poder ver una documentación vistosa de tu API, puedes introducir tu url de definición de Swagger en la URherramienta swagger ui.[http://petstore.swagger.io/](https://www.google.com/url?q=http://petstore.swagger.io/\&sa=D\&ust=1489485501837000\&usg=AFQjCNFkClaochIeZIynVgsu8eriZJR-LQ), en la casilla superior y pulsar explorar. Si quieres acceder desde una red privada puedes descargar la herramienta swagger ui a tu ordenador y generar la documentación de tu API en local [https://github.com/swagger-api/swagger-ui](https://www.google.com/url?q=https://github.com/swagger-api/swagger-ui\&sa=D\&ust=1489485501838000\&usg=AFQjCNGneyJTQcDBsU3Nkj0c4DQkFg_SOg) Desde swagger ui, no solamente puedes ver la documentación de la API, sino que podrás probar los distintos recursos y testear contra los datos reales de las aplicaciones. Recuerda introducir el API key que has puesto en vERP en la página de Swagger UI para poder simular las mismas opciones que se puedan hacer con dichao API key. **Doble factor de validación** Tras mostrarse la interfaz de Swagger, es necesario conocer el nombre de la API y asignarla a la variable “api\_name”. Una vez comprobada su validez, se mostrarán los recursos disponibles y será necesaria la validación del “api\_key” para usarlos. **Información del API Rest configurable** Los texto que se muestran en la pantalla inicial del API Rest, son obtenidos de la pestaña “Comentarios” del proyecto. Una vez validado con un api\_name, la información será sustituida por la que exista en las observaciones de la tabla del API. **Información de las tablas configurable** La información adicional mostrada en las tablas, procesos y/o búsquedas es obtenida desde el campo “Comentarios” de cada tabla. **Métodos append, cross y delete para los filtros** El filtrado por defecto realiza un *{cross}* (cruce de registros). Por ejemplo, si filtramos por los artículos que contengan la palabra “cámara” y como segundo filtro le asignamos que la familia sea “A01”, nos devolverá las cámaras cuya familia sea A01. `https://midominio.velneo.net/verp-api/vERP_2_dat_dat/v2/art_m?fields=id,name,fam&index[words]=camara&index[fam]=A01&api_key=apideejemplo` También es posible añadair registros en filtrado, usando el método *{add}.* Para que en el mismo ejemplo sume los registros que contengan la palabra cámara a los que contengan la familia A01, sería: `https://midominio.velneo.net/verp-api/vERP_2_dat_dat/v2/art_m?fields=id,name,fam&index[words]=camara&index[fam{add}]=A01&api_key=apideejemplo` También es posible quitar registros en el filtrado, mediante el método *{delete}.* Para que en el mismo ejemplo quite los registros que contengan la familia A01 dejando solo los que contengan la palabra “cámara” y no sean de la familia A01. `https://midominio.velneo.net/verp-api/vERP_2_dat_dat/v2/art_m?fields=id,name,fam&index[words]=camara&index[fam{delete}]=A01&api_key=apideejemplo` **Método filterQuery** Permite hacer un filtro sobre una búsqueda Obtener el ID, NAME y DSC de todos los artículos de la división 1: `https://midominio.velneo.net/verp-api/vERP_2_dat_dat/v2/art_m?fields=id,name,dsc&api_key=api123&filterQuery[emp_div]=1` **Agrupamiento de recursos por *****tags*** Todos los recursos mostrados por el API Rest (tablas con sus métodos, procesos y búsquedas) son agrupado por nombre de tabla y pueden mostrarse y/o ocultarse. **Interfaz** La interfaz permite añadir mediante botones más usables los parámetros de búsqueda, nuevos botones para copiar la llamada y la respuesta del API, … Ejemplos: Url Swagger vERP Demo: (clave api= api123) `https://demoapi.velneo.com/swagger/` Url Swagger para el registro de tu propia documentación: `http://petstore.swagger.io/` **Todos los artículos:** `https://demoapi.velneo.com/verp-api/vERP_2_dat_dat/v2/art_m?api_key=api123` Todos los artículos pero mostrando los campos id, name, dsc: `https://demoapi.velneo.com/verp-api/vERP_2_dat_dat/v2/art_m?fields=id%2Cname%2Cdsc&api_key=api123` Todos los artículos pero mostrando los campos id, name mediante un proceso: `https://demoapi.velneo.com/verp-api/vERP_2_dat_dat/v1/_process/art_m_bus?fields=id,name&api_key=api123` El artículo con id=1 `https://demoapi.velneo.com/verp-api/vERP_2_dat_dat/v2/art_m?index%5Bid%5D=1&api_key=api123` Los artículos con id 1, 3 y 5 `https://demoapi.velneo.com/verp-api/vERP_2_dat_dat/v2/art_m?index%5Bid%5D=1%2C%203%2C%205&api_key=api123` Todos los clientes: `https://demoapi.velneo.com/verp-api/vERP_2_dat_dat/v2/ent_m?api_key=api123` {% hint style="info" %} Si bien Swagger requiere [CORS](https://es.wikipedia.org/wiki/Intercambio_de_recursos_de_origen_cruzado) ((Cross-Origin-Resource-Sharing) si usamos el API Rest de Velneo vERP no es necesario activarlo en Apache, pues las propias cabeceras de nuestra API Rest ya lo activan directamente. {% endhint %} ## V3 Se trata de una versión mejorada de V2 con nuevas funcionalidades: * Permite la ejecución interna de la API REST sin necesidad de pasar a traves de Apache + vModApache. Ideal para ejecución interna de procesos o funcionalidades. * Habilitado método PUT para la modificación de registros. * Modificado método POST para no recibir ID por URL, sino como dato en el *body*. * Modificado método DELETE para no recibir ID por URL, sino como dato en el *body*. * Se mantiene la lectura de un único registro con GET y el ID en la url. * Nueva pestaña de índices en una configuracion de APIKEY para tablas. * Se ha mejorado la forma como documenta los elementos *index* y *filterQuery* disponible para que su implementación en [swagger.io](http://swagger.io) sea mucho mas sencilla. Para poder documentar esta nueva versión, es necesario agregar un nuevo parámetro al momento de llamar al primer *endpoint* "OPENAPI" de la siguiente manera `https://midominio.com/api/vERP_2_dat_dat/openapi?api_name=test&`**`api_version=3`** El nuevo parámetro es `api_version`. Si no se envía el parametro o se envía cualquier valor diferente de 3, entonces entenderá que va a ejecutar la V2, en caso de enviar el 3, entonces entenderá que debe documentar como V3. De igual manera, hay otro nuevo parámetro que es `?include_image_data=true` (si no se envia, se asume *false*) este parámetro es el que decide si las imágenes se devuelven en base64 como siempre (valor true) o si se hace con una nueva metodología (valor *false* por defecto). Si se hace con la nueva metodología, en lugar del base64 automáticamente retorna una URL del estilo: `https://tu-dominio.com/vERP_2_dat_dat/v3/_image/art_m/2/img` Este nuevo método permite servir imágenes de forma dinámica y optimizada para mejorar el rendimiento de las respuestas de la API y permitir que los servidores http hagan caché de esta información. Este nuevo método, aunque se publica por defecto, se valida también en base a la seguridad definida de las tablas. También se incluye la nueva posibilidad de dar alta de registros de forma masiva, ya que el método POST ahora permite recibir un array con todos los registros que se quieran dar de alta en una unica llamada, recibiendo un JSON de la siguiente manera: ```json [     {         "clave": "valor"            },     {         "clave": "valor"            },     {         "clave": "valor"            } ] ``` Para consumo interno, es necesario ejecutar el proceso V3 con un manejador de objeto para así poder asignarle valor a las variables de entrada: * `EJE_INT` (Ejecución interna): variable booleana que determina si se trata de una ejecución interna o vía API. * `URI_OBJ` (URI Objeto) : JSON que contiene la estructura mínima necesaria para su ejecución de forma interna. Como retorno, tenemos la variable `RET` la cual contendrá el resultado de la ejecución. Ejemplos de **UriObjetos** para diferentes operaciones: ```json //Operacion GET en tabla { "metodo":"GET", //***** Metodo que se ejecutara "recurso":"art_m", //**** Identificador de tabla "tabla":"velneo_verp_2_dat/ART_M", //**** Alias de proyecto + identificador de tabla "fields_campos":[ //**** Campos especificos que queremos obtener igual que el API "id,name,fam.name" ], "index":[ ], //**** Posibilidad de indicar indices especificos a ejecutar igual que el API "include":[ ], //**** Posibilidad de indicar includes de listas igual que el API "page":[ //**** Posibilidad de indicar includes de listas igual que el API "[number]=1", //**** Posibilidad de indicar el numero de pagina igual que el API "[size]=100" //**** Posibilidad de indicar el tamaño de pagina igual que el API ], "param":[ ], //**** Posibilidad de indicar valores de param igual que el API "sort":[ ], //**** Posibilidad de indicar ordenar el resultado igual que el API "body":"", //**** Para este metodo se deja vacio "filterQuery":[ ] //**** Posibilidad de indicar los filterQuery igual que el API } ``` ```json //Operacion POST en tabla { "metodo":"POST", //***** Metodo que se ejecutara "recurso":"ent_m", //**** Identificador de tabla "tabla":"velneo_verp_2_dat/ENT_M", //**** Alias de proyecto + identificador de tabla "fields_campos":[ ], //**** Campos especificos que queremos obtener igual que el API "index":[ ], //**** Posibilidad de indicar indices especificos a ejecutar igual que el API "include":[ ], //**** Posibilidad de indicar includes de listas igual que el API "page":[ //**** Posibilidad de indicar includes de listas igual que el API "[number]=1", //**** Posibilidad de indicar el numero de pagina igual que el API "[size]=100" //**** Posibilidad de indicar el tamaño de pagina igual que el API ], "param":[ ], //**** Posibilidad de indicar valores de param igual que el API "sort":[ ], //**** Posibilidad de indicar ordenar el resultado igual que el API "body":{ //**** Json con los campos a modificar. "nom_fis":"PRUEBA", "es_emp":true, "es_pre_clt":true } } ``` ```json //Operacion PUT en tabla { "metodo":"PUT", //***** Metodo que se ejecutara "recurso":"ent_m", //**** Identificador de tabla "tabla":"velneo_verp_2_dat/ENT_M", //**** Alias de proyecto + identificador de tabla "identificador":"6", //**** Identificador del registro a modificar "fields_campos":[ ], //**** Campos especificos que queremos obtener igual que el API "index":[ ], //**** Posibilidad de indicar indices especificos a ejecutar igual que el API "include":[ ], //**** Posibilidad de indicar includes de listas igual que el API "page":[ //**** Posibilidad de indicar includes de listas igual que el API "[number]=1", //**** Posibilidad de indicar el numero de pagina igual que el API "[size]=100" //**** Posibilidad de indicar el tamaño de pagina igual que el API ], "param":[ ], //**** Posibilidad de indicar valores de param igual que el API "sort":[ ], //**** Posibilidad de indicar ordenar el resultado igual que el API "body":{ //**** Json con los campos a modificar. "nom_fis":"PRUEBA", "es_emp":true, "es_pre_clt":true } }​ ``` ```json //Operacion DELETE en tabla { "metodo":"DELETE", //***** Metodo que se ejecutara "recurso":"ent_m", //**** Identificador de tabla "tabla":"velneo_verp_2_dat/ENT_M", //**** Alias de proyecto + identificador de tabla "identificador":"6", //**** Identificador del registro a eliminar "page":[ //**** Posibilidad de indicar includes de listas igual que el API "[number]=1", //**** Posibilidad de indicar el numero de pagina igual que el API "[size]=100" //**** Posibilidad de indicar el tamaño de pagina igual que el API ] }​ ``` ```json //Operacion GET BUSQUEDA en tabla { "metodo":"GET", //***** Metodo que se ejecutara "recurso":"_query", //**** Identificador fijo _query "tabla":"velneo_verp_2_dat/ENT_M", //**** Alias de proyecto + identificador de tabla "busqueda":"velneo_verp_2_app/ENT_M", //**** Alias de proyecto + identificador de la busqueda "identificador":"ent_m", //**** Identificador de la busqueda "fields_campos":[ //**** Campos especificos que queremos obtener igual que el API "id,name" ], "index":[ ], //**** Para este metodo se deja vacio pero se envia la clave "include":[ ], //**** Para este metodo se deja vacio pero se envia la clave "page":[ //**** Posibilidad de indicar includes de listas igual que el API "[number]=1", //**** Posibilidad de indicar el numero de pagina igual que el API "[size]=100" //**** Posibilidad de indicar el tamaño de pagina igual que el API ], "param":[ //**** Posibilidad de indicar valores de param igual que el API "[TXT_BUS]=Eje" ], "sort":[ ], //**** Para este metodo se deja vacio pero se envia la clave "filterQuery":[ ] //**** Para este metodo se deja vacio pero se envia la clave } ``` ```json //Operacion GET PROCESO en tabla { "metodo":"GET", //***** Metodo que se ejecutara "recurso":"_process", //**** Identificador fijo _query "tabla":"velneo_verp_2_dat/ENT_M", //**** Alias de proyecto + identificador de tabla "proceso":"velneo_verp_2_app/ENT_M", //**** Alias de proyecto + identificador del proceso "identificador":"ent_m", //**** Identificador del proceso "fields_campos":[ //**** Campos especificos que queremos obtener igual que el API "id,name" ], "index":[ ], //**** Para este metodo se deja vacio pero se envia la clave "include":[ ], //**** Para este metodo se deja vacio pero se envia la clave "page":[ //**** Posibilidad de indicar includes de listas igual que el API "[number]=1", //**** Posibilidad de indicar el numero de pagina igual que el API "[size]=100" //**** Posibilidad de indicar el tamaño de pagina igual que el API ], "param":[ //**** Posibilidad de indicar valores de param igual que el API "[TXT_BUS]=Eje" ], "sort":[ ], //**** Para este metodo se deja vacio pero se envia la clave "filterQuery":[ ] //**** Para este metodo se deja vacio pero se envia la clave } ```