Merge branch 'master' into task/notify_cmd

CHANGES_NEXT_RELEASE

@@ -4,4 +4,6 @@
 - Fix: service header to use uppercase in case of update and delete (#1528)
 - Fix: Allow to send to CB batch update for multimeasures for NGSI-LD (#1623)
 - Add: new JEXL transformations for including into an array keys that have a certain value: valuePicker and valuePickerMulti
-- Add: attribute metadata and static attributes metadata added to jexl context (#1630)
+- Add: attribute metadata and static attributes metadata added to jexl context (#1630)
+- Add /iot/groups API endpoints (as equivalent to /iot/services) (#752)
+- Deprecated: /iot/services API routes

doc/api.md

@@ -50,10 +50,10 @@
     -   [Config group API](#config-group-api)
         -   [Config group datamodel](#config-group-datamodel)
         -   [Config group operations](#config-group-operations)
-            -   [Retrieve config groups `GET /iot/services`](#retrieve-config-groups-get-iotservices)
-            -   [Create config group `POST /iot/services`](#create-config-group-post-iotservices)
-            -   [Modify config group `PUT /iot/services`](#modify-config-group-put-iotservices)
-            -   [Remove config group `DELETE /iot/services`](#remove-config-group-delete-iotservices)
+            -   [Retrieve config groups `GET /iot/groups`](#retrieve-config-groups-get-iotgroups)
+            -   [Create config group `POST /iot/groups`](#create-config-group-post-iotgroups)
+            -   [Modify config group `PUT /iot/groups`](#modify-config-group-put-iotgroups)
+            -   [Remove config group `DELETE /iot/groups`](#remove-config-group-delete-iotgroups)
     -   [Device API](#device-api)
         -   [Device datamodel](#device-datamodel)
         -   [Device operations](#device-operations)
@@ -136,9 +136,9 @@ For every config group, the pair (resource, apikey) _must_ be unique (as it is u
 which device). Those operations of the API targeting specific resources will need the use of the `resource` and `apikey`
 parameters to select the appropriate instance.
 
-Config groups can be created with preconfigured sets of attributes, service and subservice information, security information and other
-parameters. The specific parameters that can be configured for a given config group are described in the
-[Config group datamodel](#config-group-datamodel) section.
+Config groups can be created with preconfigured sets of attributes, service and subservice information, security
+information and other parameters. The specific parameters that can be configured for a given config group are described
+in the [Config group datamodel](#config-group-datamodel) section.
 
 ### Devices
 
@@ -218,7 +218,7 @@ device preprovisioning). Device measures can have four different behaviors:
     an attribute in the device's entity, for which the IoT Agent will be regitered as Context Provider. The IoT Agent
     will return an immediate response to the Context Broker, and will be held responsible of contacting the device to
     perform the command itself using the device specific protocol. Special `status` and `info` attributes should be
-    update. For each command, its `name` and `type` must be provided. For further information, please refer to 
+    update. For each command, its `name` and `type` must be provided. For further information, please refer to
     [Command execution](#command-execution) section.
 
 All of them have the same syntax, a list of objects with the following attributes:
@@ -565,17 +565,18 @@ expression. In all cases the following data is available to all expressions:
 -   `id`: device ID
 -   `entity_name`: NGSI entity Name (principal)
 -   `type`: NGSI entity type (principal)
--   `service`: device service (`Fiware-Service`) 
+-   `service`: device service (`Fiware-Service`)
 -   `subservice`: device subservice (`Fiware-ServicePath`)
 -   `staticAttributes`: static attributes defined in the device or config group
 
 Additionally, for attribute expressions (`expression`, `entity_name`), `entityNameExp` and metadata expressions
 (`expression`) the following is available in the **context** used to evalute:
 
-- measures, as `<AttributeName>`
-- metadata (both for attribute measurement in the case of NGSI-v2 measurements and static attribute) are available in the **context** under the following convention:
-`metadata.<AttributeName>.<MetadataName>` or `metadata.<StaticAttributeName>.<MetadataName>` in a similar way of defined
-for [Context Broker](https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#metadata-support)
+-   measures, as `<AttributeName>`
+-   metadata (both for attribute measurement in the case of NGSI-v2 measurements and static attribute) are available in
+    the **context** under the following convention: `metadata.<AttributeName>.<MetadataName>` or
+    `metadata.<StaticAttributeName>.<MetadataName>` in a similar way of defined for
+    [Context Broker](https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md#metadata-support)
 
 ### Examples of JEXL expressions
 
@@ -736,7 +737,8 @@ e.g.:
 }
 ```
 
-Note that there is no order into metadata structure and there is no warranty about which metadata attribute expression will be evaluated first.
+Note that there is no order into metadata structure and there is no warranty about which metadata attribute expression
+will be evaluated first.
 
 ## Measurement transformation
 
@@ -1070,21 +1072,21 @@ As part of the device to entity mapping process, the IoT Agent creates and updat
 attribute called `TimeInstant`. This timestamp is represented as two different properties of the mapped entity:
 
 -   An attribute `TimeInstant` is added to updated entities in the case of NGSI-v2, which captures as an ISO8601
-    timestamp when the associated measurement was observed. With NGSI-LD, the Standard
-    `observedAt` property is used instead
+    timestamp when the associated measurement was observed. With NGSI-LD, the Standard `observedAt` property is used
+    instead
 
--   With NGSI-v2, an attribute metadata named `TimeInstant` per active or lazy attribute mapped, which captures as an ISO8601
-    timestamp when the associated measurement (represented as attribute value) was observed. With NGSI-LD, the Standard
-    `observedAt` property-of-a-property is used instead.
+-   With NGSI-v2, an attribute metadata named `TimeInstant` per active or lazy attribute mapped, which captures as an
+    ISO8601 timestamp when the associated measurement (represented as attribute value) was observed. With NGSI-LD, the
+    Standard `observedAt` property-of-a-property is used instead.
 
 If timestamp is not explicily defined when sending the measures through the IoT Agent (for further details on how to
 attach timestamp information to the measures, please refer to the particular IoT Agent implementation documentation),
 the arrival time on the server when receiving the measurement will be used to generate a `TimeInstant` for both the
 entity attribute and the attribute metadata.
 
-This functionality can be turned on and off globaly through the use of the `timestamp` configuration flag or `IOTA_TIMESTAMP`
-variable as well as `timestamp` flag in device or group provision (in this case, the device or group level flag takes
-precedence over the global one). The default value is `true`.
+This functionality can be turned on and off globaly through the use of the `timestamp` configuration flag or
+`IOTA_TIMESTAMP` variable as well as `timestamp` flag in device or group provision (in this case, the device or group
+level flag takes precedence over the global one). The default value is `true`.
 
 The `timestamp` configuration value used, according to the priority:
 
@@ -1104,6 +1106,7 @@ the IoTA behaviour is described in the following table:
 | false                  | No                             | TimeInstant and metadata updated with server timestamp |
 | Not defined            | Yes                            | TimeInstant and metadata updated with measure value    |
 | Not defined            | No                             | TimeInstant and metadata updated with server timestamp |
+
 Some additional considerations to take into account:
 
 -   If there is an attribute which maps a measure to `TimeInstant` attribute (after
@@ -1724,7 +1727,7 @@ Config group is represented by a JSON object with the following fields:
 
 The following actions are available under the config group endpoint:
 
-#### Retrieve config groups `GET /iot/services`
+#### Retrieve config groups `GET /iot/groups`
 
 List all the config groups for the given `fiware-service` and `fiware-servicepath`. The config groups that match the
 `fiware-servicepath` are returned in any other case.
@@ -1748,14 +1751,14 @@ Successful operations return `Content-Type` header with `application/json` value
 
 _**Response payload**_
 
-A JSON object with a services field that contains an array of services that match the request. See the
-[config group datamodel](#service-group-datamodel) for more information.
+A JSON object with a `groups` field that contains an array of groups that match the request. See the
+[config group datamodel](#config-group-datamodel) for more information.
 
 Example:
 
 ```json
 {
-    "services": [
+    "groups": [
         {
             "resource": "/deviceTest",
             "apikey": "801230BJKL23Y9090DSFL123HJK09H324HV8732",
@@ -1792,7 +1795,7 @@ Example:
 }
 ```
 
-#### Create config group `POST /iot/services`
+#### Create config group `POST /iot/groups`
 
 Creates a set of config groups for the given service and service path. The service and subservice information will taken
 from the headers, overwritting any preexisting values.
@@ -1806,14 +1809,14 @@ _**Request headers**_
 
 _**Request payload**_
 
-A JSON object with a `services` field. The value is an array of config groups objects to create. See the
-[config group datamodel](#service-group-datamodel) for more information.
+A JSON object with a `groups` field. The value is an array of config groups objects to create. See the
+[config group datamodel](#config-group-datamodel) for more information.
 
 Example:
 
 ```json
 {
-    "services": [
+    "groups": [
         {
             "resource": "/deviceTest",
             "apikey": "801230BJKL23Y9090DSFL123HJK09H324HV8732",
@@ -1847,7 +1850,7 @@ _**Response headers**_
 
 Successful operations return `Content-Type` header with `application/json` value.
 
-#### Modify config group `PUT /iot/services`
+#### Modify config group `PUT /iot/groups`
 
 Modifies the information of a config group, identified by the `resource` and `apikey` query parameters. Takes a service
 group body as the payload. The body does not have to be complete: for incomplete bodies, just the attributes included in
@@ -1869,8 +1872,8 @@ _**Request headers**_
 
 _**Request payload**_
 
-A JSON object with the config group information to be modified. See the
-[config group datamodel](#service-group-datamodel) for more information.
+A JSON object with the config group information to be modified. See the [config group datamodel](config-group-datamodel)
+for more information.
 
 Example:
 
@@ -1887,7 +1890,7 @@ _**Response code**_
 -   400 MISSING_HEADERS if any of the mandatory headers is not present.
 -   500 SERVER ERROR if there was any error not contemplated above.:
 
-#### Remove config group `DELETE /iot/services`
+#### Remove config group `DELETE /iot/groups`
 
 Removes a config group, identified by the `resource` and `apikey` query parameters.
 
@@ -2324,8 +2327,8 @@ _**Response body**_
 
 Returns the current value of the server stats,
 
--   If `Accept` header contains `application/openmetrics-text`, the response has content-type
-    `application/openmetrics-text; version=1.0.0; charset=utf-8`
+-   If `Accept` header contains `application/openmetrics-text; version=(1.0.0|0.0.1)`, the response has content-type
+    `application/openmetrics-text; version=<the requested version>; charset=utf-8`
 -   Else, If `Accept` header is missing or supports `text/plain` (explicitly or by `*/*`) , the response has
     content-type `text/plain; version=0.0.4; charset=utf-8` (legacy format for [prometheus](https://prometheus.io))
 -   In any other case, returns an error message with `406` status.

doc/deprecated.md

@@ -26,6 +26,8 @@ A list of deprecated features and the version in which they were deprecated foll
 -   Bidirectinal pluging (finally removed in 3.4.0)
 -   appendMode configuration (`IOTA_APPEND_MODE` env var) (finally removed in 3.4.0)
 -   `config.stats` section, and push-mode statistics.
+-   Services API routes (`/iot/services`) in favor of the `/iot/groups`. Both are still supported, but the former is
+    deprecated.
 
 The use of Node.js v14 is highly recommended.