-
Notifications
You must be signed in to change notification settings - Fork 5
Service Catalog API
Service Catalog provides a REST(ish) API to publish and discover various services (e.g., Device Catalog, MQTT Broker).
The entry point of the Service Catalog API returns a collection of Services in the following format:
{
"id": "<string>",
"type": "ServiceCatalog",
"@context": "<string>",
"services": []
}The id field is used throughout the API and describes the location (relative URL) of the returned resource, fulfilling the indentifiability REST interface constraint. For entry point, it equals to the path in the API endpoint URL, which is configurable and defaults to /sc.
The fields type, and @context are used to enable LinkedData support and can be ignored by clients using the plain JSON API described in this document.
The services array holds an array of Services
Each service is represented in the following format:
{
"id": <string>
"type": "Service",
"name": <string>,
"description": <string>,
"meta": {},
"protocols": [
{
"type": <string>,
"endpoint": {},
"methods": [],
"content-types": [ ]
}
],
"representation": { },
"ttl": <int>,
"created": <timestamp>,
"updated": <timestamp>,
"expires": <timestamp>
}The id field is a relative URL providing a dereferenceable identifier of the service in the catalog. It is constructed as /path/ + service-id, where:
-
pathis the path in the catalog API endpoint URL -
service-idis a unique service identifier in the network and the convention is to construct it ashostname/servicename
The rest of the fields have following meanings:
-
nameis a short string describing a service (e.g., "MqttBroker") -
descriptionis a human-readable description of a service (e.g., "Demo MQTT Broker") -
metais any hashmap describing meta-information of a service -
protocolsis an array of protocols supported by a service-
typeis a short string describing the protocol (e.g., "MQTT", "REST") -
endpointis an object describing the protocol endpoint (e.g., URL for a Web API) -
methodsis an array of protocol verbs (e.g., "GET,POST,PUT,DELETE" for REST, "PUB,SUB" for MQTT) -
content-typesis an array of strings representing MIME-types defined inrepresentation
-
-
representationis a dictionary describing the MIME-types supported by a service -
ttlis an integer defining the Time-To-Live of a service registration -
created,updated, andexpiresare generated by the Device Catalog and describe TTL-related timestamps -
page,per_pageandtotalare used for pagination
Services can be exposed through different protocols, and below are conventions for describing some of them (format of entries in the protocols array).
-
type:MQTT -
endpoint:{"url": "scheme://address:port", "topic": "/topic"} -
urldescribes the broker connection information as a URL (RFC 3986) using the following URI scheme -
topicis an optional field describing the topic used by the service. If the described service itself is an MQTT broker, can be omitted - additional fields can be defined
-
methods:["PUB", "SUB"]- array of supported MQTT messaging directions. If the described service itself is an MQTT broker, this indicates whether it supports subscription, publishing, or both. -
PUB- indicates that the service publishes data via MQTT -
SUB- indicates that the service subscribes to data via MQTT -
content-types:["application/json", ...]- array of of supported MIME-types (RFC 2046). Empty means payload agnostic
See example
-
type:REST -
endpoint:{ "url": "scheme://address:port"} -
urldescribes the endpoint URL (RFC 3986) - additional fields can be defined
-
methods:["GET", "PUT", "POST", ...]- array of supported HTTP methods (RFC 2616) -
content-types:["application/json", ...]- array of supported MIME-types (RFC 2046)
A registration describing an MQTT Broker may look as follows:
{
"id": "/sc/server.example.com/MqttBroker",
"type": "Service",
"name": "MqttBroker",
"description": "Demo MQTT Broker",
"meta": {
"apiVersion": "3.1",
"serviceType": "_mqtt._tcp.server.example.com"
},
"protocols": [
{
"type": "MQTT",
"endpoint": {
"url": "tcp://server.example.com:1883"
},
"methods": [
"PUB",
"SUB"
],
"content-types": [ ]
}
],
"representation": { },
"ttl": 120,
"created": "2014-08-19T08:24:29.283372605+02:00",
"updated": "2014-08-19T09:21:19.469528757+02:00",
"expires": "2014-08-19T09:23:19.469528757+02:00"
}Note that representation and content-types fields are empty, because MQTT is a wire-level protocol.
The REST(ish) API of the Service Catalog includes CRUD to create/retrieve/update/delete service registrations and a simple filtering API to search through the catalog.
As described above, the path is a configuration parameter setting the path in the catalog API endpoint URL.
-
/pathreturns all registered services as ServiceCatalog - methods: GET
-
/path/endpoint for creating new entries in the catalog - methods: POST
-
/path/<service-id>returns a specific service registration given its unique id as a Service - methods: POST (create), GET (retrieve), PUT (update), DELETE (delete)
-
<id>id of the registration
/path/<type>/<path>/<op>/<value>- methods: GET
-
<type>is either service (returns a random matching entry) or services (returns all matching entries) -
<path>is a dot-separated path in the Service similar to json-path -
<op>is one of (equals, prefix, suffix, contains) string comparison operations -
<value>is the intended value/prefix/suffix/substring of the key identified by<path>
curl http://catalog.example.com/sc/services/meta.serviceType/prefix/_mqtt
will return all services in the catalog which meta.serviceType starts with _mqtt (as MQTT broker defined in the example above)
The Services returned in services array in ServiceCatalog are paged using the page and per_page parameters.
The results are then include the following additional entries:
-
pageis the current page (if not specified - the first page is returned) -
per_pageis the number of entries per page (if not specified - the maximum allowed is returned) -
totalis the total number of Services in the catalog
curl http://catalog.example.com/sc?page=1&per_page=10
curl http://catalog.example.com/sc/services/meta.serviceType/prefix/_mqtt?page=1&per_page=10
API version is included as a parameter to the MIME type of request/response:
application/ld+json;version=0.1
About Patchwork Toolkit
Configuration
- Configuring Device Gateway
- Configuring Devices
- Configuring Device Catalog
- Configuring Service Catalog
- Configuring Services
Deployment examples
- Singleall-in-on-box
- Multiple Device Gateways with optional central Device Catalog
- Using central Service Catalog
API for Application developers
Integrating devices
- TBD...
Third-party integrations