サブスクリプションと登録¶

Context Broker によって公開された Data API は、サブスクリプションおよび登録の両方を実装します。共通フィールド(id, エンティティ, 属性, 期間, URLなど)と共通のダイナミクス(どちらも Context Broker が送信リクエストを送信することに関係します)と同様に見えるかもしれませんが、実際にはかなり異なっており、異なる目的に対処しています。

一方のサブスクリプションでは :

POST /v2/subscriptions
Content-Type: application/json
Fiware-service: smartown
Fiware-servicepath: /roads

{
  "subject": {
    "entities": [
      {
        "idPattern": ".*",
        "type": "Car"
      }
    ],
    "condition": {
        "attrs": [ "speed" ]
    }
  },
  "notification": {
    "http": {
        "url": "http://example.com/receiver"
    }
  }
}

• いくつかの条件が発生したときに通知を設定するために使用されます。この機能の概要については、このドキュメントを参照してください 。
• サブスクリプションに関連するURLは、サブスクリプションによってカバーされる通知が送信される通知レシーバを識別します。
• Context Brokerからレシーバへの単方向通信が必要です。言い換えれば、レシーバは、HTTPレベルでの通知配信自体の結果を超えて、Context Brokerに情報を返送しません。
• サブスクリプション管理は、NGSIv2仕様の一部です。

他方の登録では :

POST /v1/registry/registerContext
Content-Type: application/json
Fiware-service: smartown
Fiware-servicepath: /roads

{
  "contextRegistrations": [
    {
      "entities": [
        {
          "type": "Car",
          "isPattern": "false",
          "id": "FBH4452"
        }
      ],
      "attributes": [
        {
          "name": "speed",
          "type": "Number",
          "isDomain": "false"
        }
      ],
      "providingApplication": "http://myproviders.com/Cars"
    }
  ],
  "duration": "P1M"
}

• コンテキスト・ソース(コンテキスト・プロバイダとも呼ばれます)を構成するために使用されます。詳細については、Context Broker のドキュメントを参照してください。
• 登録に関連するURLは、登録によってカバーされるコンテキスト・プロバイダへのクエリまたは更新の転送に使用されます。
• クエリ転送の場合、コンテキスト・プロバイダはクエリ応答の一部としてクエリ結果を Context Broker に送信します。したがって、コンテキストプロバイダから Context Broker への情報フローがあります。
• IoT platform v4.1になるまでには、登録管理はまだ NGSIv2 の一部ではないため、古い NGSIv1 API を使用する必要があります。ただし、登録の結果として転送されたクエリ/更新は問題なく NGSIv2 を使用できます。この共存についての詳細はこちらを参照ください。