Version: 3 May 2023
Editors:
Michael Lagally (Oracle Corp.)
Michael McCool (Intel Corp.)
Ryuichi Matsukura (Fujitsu Ltd.)
Sebastian Kaebisch (Siemens AG)
Tomoaki Mizushima (Internet Research Institute, Inc.)
Copyright © 2019 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
The Web of Things (WoT) Profile document entered the Candidate Recommendation period for the second time on DD-MM-2022.
The planned date for entering Proposed Recommendation is DD-MM-2022. This document summarizes the results from the Web of Things (WoT) TD implementer reports received and describes the process that the Web of Things (WoT) Working Group followed in preparing this Implementation Report (IR).
Although results were generated with a combination of automated and manual tests, the automated tests were only meant to provide assistance to implementers in preparing their individual implementation test reports.
During the CR period, the Working Group carried out the following activities:
Implementers were invited to contribute to the assessment of the Web of Things (WoT) Profile Candidate Recommendation by submitting implementer reports describing the coverage of their implementations with respect to the test assertions outlined in the table below.
Implementer reports were collected through the W3C WoT Interest Group's
PlugFest activity and collected
in the GitHub repository
https://github.com/w3c/wot
under testing/tests/2022-mm/.
Comments on this document, or requests made for further information were posted to the Working Group's public mailing list wot-wg@w3.org (archive) and as issues on the GitHub repository https://github.com/w3c/wot-profile.
The Web of Things (WoT) Working Group established the following entrance criteria for the Proposed Recommendation phase in the Request for CR:
All three of these criteria have been met. The testimonials below indicate the broad base of support for the specification. All of the required features had at least two implementations. All of the optional features also received at least one implementation. However, these optional features do not have conformance requirements that have an impact on interoperability.
Feature status is in practice indicated by RFC 2119 assertions associated with the feature. Features defined using any assertions containing the words MUST are considered required. Features defined using MAY and SHOULD assertions are considered optional.
pass, fail, or not-impl (not implemented).
This implementation Report will not cover:
This section contains descriptions of each of the implementations of the WoT Profile specification from all organizations that submitted implementer reports. Each implementation represents a working system that is based on the WoT Profile.
We only count systems with mostly independent code bases as distinct implementations. There are however some cases (documented in the following) where implementations shared components but were still considered substantially independent implementations. In cases where a substantial component was shared across implementations the features supported by that component were only counted once.
The Web of Things (WoT) Profile specification describes systems that include features to support security. Functional aspects of assertions associated with security features are validated in the same fashion as other functional features. In addition, however, the Web of Things (WoT) WG Charter requires the development of a test plan. An appropriate security test plan, including a description of how existing web service penetration testing tools can be used, in addition to a description of more general security and privacy considerations, is included in Web of Things (WoT) Security and Privacy Guidelines.
The aim of this section is to summarize the assertions from the Web of Things (WoT) Profile document and summarize the results from the implementation reports received in the CR period. The tables in each section below lists all assertions derived from the Web of Things (WoT) Profile document. The results are broken into two parts: those for which automated testing has been implemented, and those for which it has not and manual testing and reporting was necessary.
The headers for these tables are described as follows:
pass (P),
fail (F), and
not-impl (N)
status results in the individual implementer reports.
In the case of assertions with multiple mutually exclusive options (for example, enumerated values) each of these options may be tested separately and the results combined. In this case the 'pass' and 'total' values reported are the minimum value of any of the more detailed tests, while the 'fail' and 'not implemented' values report the maximum value of any of these tests. Since minimum and maximum value may be drawn from different detailed tests, the sum of the 'pass', 'fail', and 'not implemented' cases may not equal the 'total'. Instead the total represents the number of implementations for which all options were tested. For such cases the "child" assertions have underscores in their names prior to each value tested and the table row is also rendered in a different color.
The following assertions have been validated by automated testing using the ThingWeb Playground AssertionTester.
| ID | Category | Req | Context | Assertion | Parent | Results | |||
|---|---|---|---|---|---|---|---|---|---|
| P | F | N | T | ||||||
| 5: profiling-mechanism-5 | Y | All Things and Consumers conforming to a profile MUST satisfy the assertions specified in the [[wot-thing-description11]], except for the assertion td-context-ns-td10-namespacev10 with text TD 1.1 consumers MUST accept TDs satisfying the W3C WoT Thing Description 1.0 [wot-thing-description] specification. | 0 | 0 | 0 | 0 | |||
| 14: common-constraints-security-4 | Y | A Thing MUST support at least one of the above security schemes. | 3 | 0 | 0 | 3 | |||
| 15: common-constraints-security-basic-in | Y | For the BasicSecurityScheme the "in" field MUST be either omitted or be given its default value of "header" as defined in [[wot-thing-description11]. | 0 | 0 | 0 | 0 | |||
| 16: common-constraints-security-basic-name | Y | For the BasicSecurityScheme the "name" field MUST be provided using the value "Authorization" if a "proxy" endpoint is not given. | 0 | 0 | 0 | 0 | |||
| 17: common-constraints-security-basic-proxy | Y | For the BasicSecurityScheme the "name" field MUST be provided using the value "Proxy-Authorization" if a"proxy" endpoint is given. | 0 | 0 | 0 | 0 | |||
| 26: common-constraints-links-media-types-4 | Consumer | N | If a Consumer encounters a link with "rel": "icon" and "type": "image/*" and it is capable of rendering images in the provided format, then it SHOULD interpret the link as an icon for the Thing and display it to the user. | 0 | 1 | 0 | 1 | ||
| 27: common-constraints-links-media-types-5 | Consumer | N | If a Consumer encounters a link with "rel": "alternate" and "type": "text/html" and it is capable of rendering an HTML page and accepting user input, then it SHOULD interpret the link as a user interface for the Thing and provide a means for the user to follow that link and view and interact with the HTML page. | 0 | 1 | 0 | 1 | ||
| 28: common-constraints-links-media-types-6 | Consumer | N | If a Consumer encounters a link with "rel": "service-doc" and "type": "text/plain", "type": "text/html" or "type": "text/pdf", and is capable of rendering documents in the provided format, then it SHOULD interpret the link as a user manual for the Thing and provide a means for the user to follow that link and read the user manual. | 0 | 1 | 0 | 1 | ||
| 29: common-constraints-links-media-types-7 | Consumer | N | If a Consumer encounters a link with "rel": "item" and "type": "application/td+json" and is capable of rendering a hierarchical tree of Things, then it should interpret the link as an indication that the target is a sub-Thing of the current Thing and render this in a meaningful way to the user. | 0 | 1 | 0 | 1 | ||
| 30: common-constraints-links-media-types-8 | Consumer | N | If a Consumer encounters a link with "rel": "collection" and "type": "application/td+json" and is capable of rendering a hierarchical tree of Things, then it should interpret the link as an indication that the target describes a Thing (e.g. a group, system of Things or Thing Directory) which contains the current Thing and render this in a meaningful way to the user. | 0 | 1 | 0 | 1 | ||
| 77: http-basic-profile-protocol-binding-invokeaction-22 | N | In resource constrained environments, the ActionStatus objects of older completed/failed actions MAY be deleted to make room for newly invoked actions. | 0 | 0 | 0 | 0 | |||
| 78: http-basic-profile-protocol-binding-invokeaction-23 | N | A Web Thing SHOULD return a 503 error response if the invocation cannot be accepted because the action is unavailable, e.g. because the Thing is overloaded. | 0 | 1 | 0 | 1 | |||
| 151: http-webhook-profile-notification-format-1 | Y | Notification messages MUST comply with the following data schema. | 0 | 0 | 0 | 0 | |||
| 159: http-webhook-profile-protocol-binding-observeproperty-1 | Y | The URL of a Property resource to be used when observing the value of a property MUST be obtained from a Thing Description by locating a Form inside the corresponding PropertyAffordance for which: Its op member contains the value observeproperty After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https Its Content-Type header has a value of application/json Its subprotocol member has a value of webhook | 0 | 0 | 0 | 0 | |||
| 160: http-webhook-profile-protocol-binding-observeproperty-2 | Y | The resolved value of the href member MUST then be used as the URL of the Property resource. | 0 | 0 | 0 | 0 | |||
| 161: http-webhook-profile-protocol-binding-observeproperty-3 | Y | In order to observe a property, a Consumer MUST provide the listener URL in the request payload of the observeproperty operation of the Property resource. | 0 | 0 | 0 | 0 | |||
| 162: http-webhook-profile-protocol-binding-observeproperty-5 | Y | If a Web Thing receives an HTTP request following the format above and the Consumer has permission to observe the corresponding property, then it MUST send a notification to the Consumer each time the value of the specified property changes. | 0 | 0 | 0 | 0 | |||
| 163: http-webhook-profile-protocol-binding-observeproperty-6 | Y | Whenever a change of the property occurs, the Web Thing MUST send the new value to the Consumer with an HTTP POST request with a Content-Type header set to application/json, in the payload format defined in section ["#http-webhook-profile-protocol-binding-notification-format"]. | 0 | 0 | 0 | 0 | |||
| 164: http-webhook-profile-protocol-binding-unobserveproperty-1 | Y | In order to stop observing a property, a Consumer MUST terminate the corresponding subscription with the Web Thing using the unobserveproperty operation of the Property resource. | 0 | 0 | 0 | 0 | |||
| : http-webhook-profile-protocol-binding-subscribeevent-5-1 | N | If a Web Thing receives an HTTP request following the format above and the Consumer has previously subscribed to the corresponding property with the subscriptionID provided, then the subscription is cancelled. | 0 | 0 | 0 | 0 | |||
| : http-webhook-profile-protocol-binding-subscribeevent-5-2 | Y | If a Web Thing receives an HTTP request following the format above and the Consumer has permission to subscribe to the corresponding event, then it MUST send notification messages to the Consumer as events of the specified type occur. | 0 | 0 | 0 | 0 | |||
| : http-webhook-profile-protocol-binding-subscribeevent-5-3 | N | If a Web Thing receives an HTTP request following the format above and the Consumer has subscribed to the corresponding event with the subscriptionID provided, then the subscription is cancelled. | 0 | 0 | 0 | 0 | |||
| : http-webhook-profile-protocol-binding-subscribeevent-5-4 | N | If a Web Thing receives an HTTP request following the format above and the Consumer has previously subscribed to the root event with the subscriptionID provided, then the subscription is cancelled. | 0 | 0 | 0 | 0 | |||
| 166: http-webhook-profile-protocol-binding-observeallproperties-1 | Y | The URL of a Properties resource to be used when observing changes to all properties of a Web Thing MUST be obtained from a Thing Description by locating a Form inside the top level forms member of a Thing Description for which: Its op member contains the value observeallproperties After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https Its Content-Type header has a value of application/json Its subprotocol member has a value of webhook | 0 | 0 | 0 | 0 | |||
| 167: http-webhook-profile-protocol-binding-observeallproperties-2 | Y | The resolved value of the href member MUST then be used as the URL of the properties resource. | 0 | 0 | 0 | 0 | |||
| 168: http-webhook-profile-protocol-binding-observeallproperties-3 | Y | In order to observe changes to all properties of a Web Thing, a Consumer MUST send an HTTP request to the Web Thing with: | 0 | 0 | 0 | 0 | |||
| 169: http-webhook-profile-protocol-binding-observeallproperties-4 | Y | If a Web Thing receives an HTTP request following the format above, then it MUST send notifications to the Consumer for all properties for which it has permission to subscribe. | 0 | 0 | 0 | 0 | |||
| 170: http-webhook-profile-protocol-binding-observeallproperties-5 | Y | Whenever a property changes while a Consumer is oberving Properties, the Web Thing MUST send the new value to the Consumer with an HTTP POST request with a Content-Type header set to application/json, and the payload format defined in section ["#http-webhook-profile-protocol-binding-notification-format"]. | 0 | 0 | 0 | 0 | |||
| 171: http-webhook-profile-protocol-binding-unobserveallproperties-1 | Y | In order to unobserve all properties, a Consumer MUST invoke the unobserveallproperties operation of the Property resource. | 0 | 0 | 0 | 0 | |||
| 177: http-webhook-profile-protocol-binding-unsubscribeevent-1 | Y | In order to unsubscribe to an event, a Consumer MUST terminate the corresponding subscription with the Web Thing using the unsubscribeevent operation of the Event resource. | 0 | 0 | 0 | 0 | |||
| 187: http-webhook-profile-protocol-binding-event-connections-1a | N | Notifications must be sent with an HTTP POST request with a Content-Type header set to application/json. | 0 | 0 | 0 | 0 | |||
| 192: http-webhook-profile-protocol-binding--event-connections-8a | Y | If the response to an notification by the Consumer does not contain a payload, the Consumer MUST respond with an HTTP 204 No Content response code. | 0 | 0 | 0 | 0 | |||
The following assertions have been manually validated by the implementers.
| ID | Category | Req | Context | Assertion | Parent | Results | |||
|---|---|---|---|---|---|---|---|---|---|
| P | F | N | T | ||||||
| 1: profiling-mechanism-1 | Thing | Y | In order to conform with a profile, a Web Thing MUST conform with all the normative statements in the profile's specification. | 0 | 1 | 1 | 2 | ||
| 2: profiling-mechanism-2 | TD Thing | Y | In order to denote that a given Web Thing conforms to one or more profiles, its Thing Description MUST include a profile member [[wot-thing-description11]]. | 4 | 0 | 1 | 5 | ||
| 3: profiling-mechanism-3 | TD | Y | The value of the profile member MUST be set to either a valid URI [[RFC3986]] identifying a single profile, or an array of valid URIs identifying multiple profiles. | 4 | 0 | 1 | 5 | ||
| 4: profiling-mechanism-4 | TD | Y | In order to use a profile member in a Thing Description, the @context member MUST contain the anyURI https://www.w3.org/2022/wot/td/v1.1 in order to denote that the document is using version 1.1 of the Thing Description specification. [[wot-thing-description11]]. | 4 | 0 | 1 | 5 | ||
| 6: common-constraints-a11y-1 | TD | Y | It is REQUIRED to provide a title that can be automatically rendered in a non-visual way (e.g. using a screen reader) for things that may be used in deployments with users with disabilities. | 0 | 1 | 0 | 1 | ||
| 7: common-constraints-a11y-2 | TD | N | It is highly RECOMMENDED to provide a description that can be automatically rendered in a non-visual way (e.g. using a screen reader) for things that may be used in deployments with users with disabilities. | 0 | 1 | 0 | 1 | ||
| 8: common-constraints-units | TD | N | It is highly RECOMMENDED to provide a unit, if a value has a physical quantity. | 3 | 0 | 1 | 4 | ||
| 9: common-constraints-units-metric | TD | N | It is highly RECOMMENDED to use the metric system (SI units) for devices that are used in global deployments. | 3 | 0 | 1 | 4 | ||
| 10: common-constraints-date-format-1 | TD | Y | All date and time values MUST use the date-time format defined in [[RFC3339]]. | 4 | 0 | 0 | 4 | ||
| 11: common-constraints-security-1 | TD Thing | N | Below is a list of security schemes [[wot-thing-description]] which conformant Web Things MAY use: NoSecurityScheme BasicSecurityScheme OAuth2SecurityScheme with the code or client flow. | 4 | 0 | 0 | 4 | ||
| 12: common-constraints-security-2 | Consumer | Y | Conformant Consumers MUST support at least all of these security schemes. | 0 | 1 | 3 | 4 | ||
| 13: common-constraints-security-3 | TD Thing | N | A Thing MAY implement multiple security schemes. | 3 | 0 | 1 | 4 | ||
| 18: common-constraints-security-6 | Consumer | Y | Conformant Consumers MUST support security bootstrapping for all implemented security schemes, as defined in Security Bootstrapping in the WoT Discovery [[wot-discovery]] specification. | 1 | 0 | 2 | 3 | ||
| 19: common-constraints-security-7 | Thing | Y | Conformant Things which require authentication in order to retrieve their Thing Description MUST implement security bootstrapping, as defined in Security Bootstrapping in the WoT Discovery [[wot-discovery]] specification. | 0 | 1 | 2 | 3 | ||
| 20: common-constraints-discovery-1 | Thing | Y | A Web Thing's Thing Description [[wot-thing-description]] MUST be retrievable from a Thing Description Server [[wot-architecture11]] using an HTTP [[HTTP11]] URL provided by a Direct Introduction Mechanism [[wot-discovery]]. | 4 | 0 | 1 | 5 | ||
| 21: common-constraints-links-1 | TD | N | The following keywords are defined for links in the HTTP profiles and MAY be present in profile-compliant TDs with the constraints defined by this section. | 0 | 0 | 2 | 2 | ||
| 22: common-constraints-links-2 | TD | N | Other keywords for links MAY be present in a TD, however their interpretation is undefined in the context of the HTTP profiles | 4 | 0 | 0 | 4 | ||
| 23: common-constraints-links-3 | Consumer | N | These other link types MAY be ignored by all profile-compliant consumers. | 1 | 0 | 2 | 3 | ||
| 24: common-constraints-links-media-types-1 | TD | N | The following media types from IANA MAY be used as the link targets of profile compliant TDs with the constraints in this section. | 0 | 0 | 3 | 3 | ||
| 25: common-constraints-links-media-types-2 | TD Consumer | N | Other media types MAY be present in a TD, however their heir interpretation is undefined in the context of the HTTP profiles and they MAY be ignored by all profile-compliant consumers. | 1 | 0 | 3 | 4 | ||
| 31: common-constraints-errors-1 | Thing | Y | If any of the operations defined in the protocol bindings of HTTP profiles are unsuccessful then the Web Thing MUST send an HTTP response with an HTTP error code which describes the reason for the failure. | 5 | 0 | 0 | 5 | ||
| 32: common-constraints-errors-2 | Thing | N | It is RECOMMENDED that error responses use one of the following HTTP error codes: 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 500 Internal Server Error 503 Service Unavailable | 5 | 0 | 0 | 5 | ||
| 33: common-constraints-errors-3 | Thing | N | A Web Thing MAY respond with 3xx status codes for the purposes of redirection, caching or authentication. | 0 | 0 | 4 | 4 | ||
| 34: common-constraints-errors-4 | Thing | Y | A Web Thing MUST NOT respond with a 300 Multiple Choices status code. | 4 | 0 | 1 | 5 | ||
| 35: common-constraints-errors-5 | Thing | N | Web Things MAY respond with other valid HTTP error codes (e.g. 418 I'm a teapot). | 4 | 0 | 0 | 4 | ||
| 36: common-constraints-errors-6 | Consumer | N | Consumers MAY interpret other valid HTTP error codes as a generic 4xx or 5xx error with no special defined behaviour. | 1 | 0 | 2 | 3 | ||
| 37: common-constraints-errors-7 | Thing | Y | If an HTTP error response contains a body, the content of that body MUST conform with the Problem Details format [[RFC7807]]. | 3 | 1 | 1 | 5 | ||
| 38: common-constraints-default-language | TD | Y | One Map contained in an @context Array MUST contain a name-value pair that defines the default language for the Thing Description, where the name is the Term @language and the value is a well-formed language tag as defined by [BCP47] (e.g., en, de-AT, gsw-CH, zh-Hans, zh-Hant-HK, sl-nedis). | 2 | 1 | 1 | 4 | ||
| 39: http-basic-profile-1 | Thing Consumer | Y | In order to conform with the HTTP Basic Profile, Web Things and Consumers MUST also conform with all of the assertions in the Common Constraints section. | 1 | 1 | 1 | 3 | ||
| 40: http-basic-profile-identifier-1 | TD | Y | In order to denote that a given Web Thing conforms to the HTTP Basic Profile, its Thing Description MUST have a profile member [[wot-thing-description]] with a value of https://www.w3.org/2022/wot/profile/http-basic/v1. | 4 | 0 | 1 | 5 | ||
| 41: profile-5-2-thing-protocol-binding-1 | Consumer Thing | Y | A Consumer or Web Thing conforming to the HTTP Basic Profile MUST implement this protocol binding. | 2 | 0 | 3 | 5 | ||
| 42: http-basic-profile-protocol-binding-readproperty-1 | TD | Y | The URL of a Property resource to be used when reading the value of a property MUST be obtained from a Thing Description by locating a Form inside the corresponding PropertyAffordance for which: After defaults have been applied, its op member contains the value readproperty. After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https | 3 | 0 | 0 | 3 | ||
| 43: http-basic-profile-protocol-binding-readproperty-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Property resource. | 2 | 0 | 1 | 3 | ||
| 44: http-basic-profile-protocol-binding-readproperty-4 | Consumer | Y | In order to read the value of a property, a Consumer MUST send an HTTP request to a Web Thing with: Method set to GET URL set to the URL of the Property resource Accept header set to application/json | 2 | 0 | 1 | 3 | ||
| 45: http-basic-profile-protocol-binding-readproperty-6 | Thing | Y | If a Web Thing receives an HTTP request following the format above and the Consumer has permission to read the corresponding property, then upon successfully reading the value of the property it MUST send an HTTP response with: Status code set to 200 Content-Type header set to application/json A body with the value of the property serialized in JSON | 5 | 0 | 0 | 5 | ||
| 46: http-basic-profile-protocol-binding-writeproperty-1 | Consumer | Y | The URL of a Property resource to be used when writing the value of a property MUST be obtained from a Thing Description by locating a Form inside the corresponding PropertyAffordance for which: After defaults have been applied, its op member contains the value writeproperty After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https | 3 | 0 | 0 | 3 | ||
| 47: http-basic-profile-protocol-binding-writeproperty-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Property resource. | 2 | 0 | 1 | 3 | ||
| 48: http-basic-profile-protocol-binding-writeproperty-4 | Consumer | Y | In order to write the value of a property, a Consumer MUST send an HTTP request to a Web Thing with: Method set to PUT URL set to the URL of the Property resource Content-Type header set to application/json A body with a requested new value for the property serialized in JSON | 2 | 0 | 1 | 3 | ||
| 49: http-basic-profile-protocol-binding-writeproperty-6 | Thing | Y | If a Web Thing receives an HTTP request following the format above and the Consumer has permission to write the corresponding property, then upon successfully writing the value of the property it MUST send an HTTP response with: Status code set to 204 | 3 | 0 | 0 | 3 | ||
| 50: http-basic-profile-protocol-binding-readallproperties-1 | Consumer | Y | The URL of a Properties resource to be used when reading the value of all properties at once MUST be obtained from a Thing Description by locating a Form inside the top level forms member for which: Its op member contains the value readallproperties After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https | 4 | 0 | 0 | 4 | ||
| 51: http-basic-profile-protocol-binding-readallproperties-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Properties resource. | 2 | 0 | 2 | 4 | ||
| 52: http-basic-profile-protocol-binding-readallproperties-4 | Consumer | Y | In order to read the value of all properties, a Consumer MUST send an HTTP request to a Web Thing with: Method set to GET URL set to the URL of the Properties resource Accept header set to application/json | 3 | 0 | 1 | 4 | ||
| 53: http-basic-profile-protocol-binding-readallproperties-5 | Thing | Y | If a Web Thing receives an HTTP request following the format above, then upon successfully reading the values of all the readable properties to which the Consumer has permission to access, it MUST send an HTTP response with: Status code set to 200 Content-Type header set to application/json A body with the values of all readable properties serialized in JSON, as an object keyed by property name | 4 | 0 | 0 | 4 | ||
| 54: http-basic-profile-protocol-binding-writemultipleproperties-1 | Consumer | Y | The URL of a Properties resource to be used when writing the value of multiple properties at once MUST be obtained from a Thing Description by locating a Form inside the top level forms member for which: Its op member contains the value writemultipleproperties After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https | 2 | 0 | 0 | 2 | ||
| 55: http-basic-profile-protocol-bindings-writemultipleproperties-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Properties resource. | 1 | 0 | 1 | 2 | ||
| 56: http-basic-profile-protocol-binding-writemultipleproperties-4 | Consumer | Y | In order to write the value of multiple properties at once, a Consumer MUST send an HTTP request to a Web Thing with: Method set to PUT URL set to the URL of the Properties resource Content-Type header set to application/json A body with requested new values for the writable properties serialized in JSON, as an object keyed by property name | 2 | 0 | 0 | 2 | ||
| 57: http-basic-profile-protocol-binding-writemultipleproperties-6 | Thing | Y | If a Web Thing receives an HTTP request following the format above, then upon successfully writing the values of the requested writable properties it MUST send an HTTP response with: Status code set to 204 | 2 | 0 | 1 | 3 | ||
| 58: http-basic-profile-protocol-binding-invokeaction-1 | Consumer | Y | The URL of an Action resource to be used when invoking an action MUST be obtained from a Thing Description by locating a Form inside the corresponding ActionAffordance for which: After defaults have been applied, the value of its op member is invokeaction After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https | 2 | 0 | 0 | 2 | ||
| 59: http-basic-profile-protocol-binding-invokeaction-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Action resource. | 1 | 0 | 1 | 2 | ||
| 60: http-basic-profile-protocol-binding-invokeaction-4 | Consumer | Y | In order to invoke an action on a Web Thing, a Consumer MUST send an HTTP request to the Web Thing with: Method set to POST URL set to the URL of the Action resource Accept header set to application/json Content-Type header set to application/json A body with an input to the action, if any, serialized in JSON | 2 | 0 | 0 | 2 | ||
| 61: http-basic-profile-protocol-binding-invokeaction-6 | Thing | Y | If a Web Thing receives an HTTP request following the format above then it MUST respond with one of three response formats: Synchronous Action Response Asynchronous Action Response Error Response | 3 | 0 | 0 | 3 | ||
| 62: http-basic-profile-protocol-binding-invokeaction-7 | Thing | Y | If the synchronous member of the ActionAffordance [[wot-thing-description11]] is set to true then the Web Thing MUST respond with a Synchronous Action Response. | 1 | 0 | 0 | 1 | ||
| 63: http-basic-profile-protocol-binding-invokeaction-8 | Thing | Y | If the synchronous member of the ActionAffordance [[wot-thing-description11]] is set to false then the Web Thing MUST respond with an Asynchronous Action Response. | 2 | 0 | 1 | 3 | ||
| 64: http-basic-profile-protocol-binding-invokeaction-9 | Thing | N | If the synchronous member of the ActionAffordance [[wot-thing-description11]] is undefined then the Web Thing MAY respond with either a Synchronous Action Response or Asynchronous Action Response. | 3 | 0 | 0 | 3 | ||
| 65: http-basic-profile-protocol-binding-invokeaction-10 | Thing | N | For long-running actions which are not expected to finish executing within the timeout period of an HTTP request (e.g. 30 to 120 seconds), it is RECOMMENDED that a Web Thing respond with an Asynchronous Action Response so that a Consumer may continue to monitor the status of an action request with a queryaction operation on a dynamically created ActionStatus resource, after the initial invokeaction response. | 4 | 0 | 0 | 4 | ||
| 66: http-basic-profile-protocol-binding-invokeaction-11 | Thing | N | For short-lived actions which are expected to finish executing within the timeout period of an HTTP request, a Web Thing MAY wait until the action has completed to send a Synchronous Action Response. | 1 | 0 | 0 | 1 | ||
| 67: http-basic-profile-protocol-binding-invokeaction-12 | Thing | Y | If a Web Thing encounters an error in attempting to execute an action before responding to the invokeaction request, then it MUST send an Error Response. | 2 | 0 | 1 | 3 | ||
| 68: http-basic-profile-protocol-binding-invokeaction-13 | Consumer | Y | Conforming Consumers MUST support all three types of response to the initial invokeaction request. | 0 | 0 | 3 | 3 | ||
| 69: http-basic-profile-protocol-binding-invokeaction-14 | Consumer Thing | N | After the initial request, support for subsequent operations on an ActionStatus resource is OPTIONAL. | 1 | 0 | 0 | 1 | ||
| 70: http-basic-profile-protocol-binding-invokeaction-15 | Consumer Thing TD | Y | The status of an asynchronous action invocation request is represented by an ActionStatus object which includes the following members: Member Description Assignment Type status The status of the action request. mandatory string (one of pending, running, completed or failed) output The output data, if any, of a completed action which MUST conform with the output data schema of the corresponding ActionAffordance. optional any type error An error message, if any, associated with a failed action which MUST use the JSON serialization of the Problem Details format [[RFC7807]] (only needed in response to a queryaction operation). optional object href The [[URL]] of an ActionStatus resource which can be used by queryaction and cancelaction operations, the URI scheme [[RFC3986]] of which MUST resolve to http or https (only needed for an Asynchronous Action Response). optional string timeRequested A timestamp indicating the time at which the Thing received the request to execute the action. (See Date Format for date format constraints). optional string timeEnded A timestamp indicating the time at which the Thing successfully completed executing the action, or failed to execute the action. (See Date Format for date format constraints). optional string | 2 | 0 | 2 | 4 | ||
| 71: http-basic-profile-protocol-binding-invokeaction-16 | TD | Y | status: The status of the action request. MUST be included. Type: string (one of pending, running, completed or failed) . | 1 | 0 | 0 | 1 | ||
| 72: http-basic-profile-protocol-binding-invokeaction-17 | TD | Y | output: The output data, if any, of a completed action which MUST conform with the output data schema of the corresponding ActionAffordance. MAY be included. Type: any type. | 0 | 0 | 1 | 1 | ||
| 73: http-basic-profile-protocol-binding-invokeaction-18 | TD Thing | Y | error: An error message, if any, associated with a failed action which MUST use the JSON serialization of the Problem Details format [[RFC7807]] (only needed in response to a queryaction operation). MAY be included. Type: object. | 1 | 0 | 0 | 1 | ||
| 74: http-basic-profile-protocol-binding-invokeaction-19 | TD | Y | href: The [[URL]] of an ActionStatus resource which can be used by queryaction and cancelaction operations, the URI scheme [[RFC3986]] of which MUST resolve to http or https (only needed for an Asynchronous Action Response). MAY be included. Type: string. | 1 | 0 | 0 | 1 | ||
| 75: http-basic-profile-protocol-binding-invokeaction-20 | Thing | Y | If providing a Synchronous Action Response, a Web Thing MUST send an HTTP response with: Status code set to 200 Content-Type header set to application/json A body containing the output of the action, if any, serialized in JSON | 1 | 0 | 0 | 1 | ||
| 76: http-basic-profile-protocol-binding-invokeaction-21 | Thing | Y | If providing an Asynchronous Action Response, a Web Thing MUST send an HTTP response containing the URL of an ActionStatus resource, the URI scheme [[RFC3986]] of which MUST resolve to http or https. The response MUST have: Status code set to 201 Content-Type header set to application/json Location header set to the URL of the ActionStatus resource A body containing an ActionStatus object serialized in JSON, with its href member set to the URL of the ActionStatus resource | 2 | 0 | 0 | 2 | ||
| 79: http-basic-profile-protocol-binding-queryaction-1a | Thing TD | Y | A Web Thing which provides Asynchronous Action Responses to an invokeaction operation on an Action MUST also support queryaction operations on that same Action. | 3 | 0 | 1 | 4 | ||
| 80: http-basic-profile-protocol-binding-queryaction-1b | Thing TD | N | A Web Thing which only provides Synchronous Action Responses to an invokeaction operation on an Action SHOULD NOT support queryaction operations on that same Action. | 2 | 0 | 0 | 2 | ||
| 81: http-basic-profile-protocol-binding-queryaction-2 | Consumer TD | Y | The URL of an ActionStatus resource to be used in a queryaction operation MUST be obtained from the Location header of an Asynchronous Action Response, or the href member of the ActionStatus object in its body. | 1 | 0 | 1 | 2 | ||
| 82: http-basic-profile-protocol-binding-queryaction-3 | Consumer | Y | In order to query the status of an action request, a Consumer MUST send an HTTP request to a Web Thing with: Method set to GET URL set to the URL of the ActionStatus resource Accept header set to application/json | 0 | 0 | 2 | 2 | ||
| 83: http-basic-profile-protocol-binding-queryaction-5 | Thing | Y | If a Web Thing receives an HTTP request following the format above and the Consumer has permission to query the corresponding ActionStatus resource, then upon successfully reading the status of the action request it MUST send an HTTP response with: Status code set to 200 Content-Type header set to application/json A body containing an ActionStatus object representing the current status of the action request, serialized in JSON | 3 | 0 | 1 | 4 | ||
| 84: http-basic-profile-protocol-binding-queryaction-7a | Thing | Y | If the queried action failed to execute, then the status member of the ActionStatus object MUST be set to "failed". | 2 | 1 | 1 | 4 | ||
| 85: http-basic-profile-protocol-binding-queryaction-7b | Thing | N | If the queried action failed to execute, then the error member MAY provide additional error information conforming to the Problem Details format [[RFC7807]]. | 2 | 0 | 1 | 3 | ||
| 86: http-basic-profile-protocol-binding-cancelaction-1a | Thing | N | A Web Thing which provides Asynchronous Action Responses to an invokeaction operation on an Action MAY also support cancelaction operations on that same Action. | 3 | 0 | 1 | 4 | ||
| 87: http-basic-profile-protocol-binding-cancelaction-1b | Thing | N | A Web Thing which only provides Synchronous Action Responses to an invokeaction operation on an Action SHOULD NOT support cancelaction operations on that same Action. | 2 | 0 | 1 | 3 | ||
| 88: http-basic-profile-protocol-binding-cancelaction-2 | Consumer | Y | The URL of an ActionStatus resource to be used in a cancelaction operation MUST be obtained from the Location header of an Asynchronous Action Response, or the href member of the ActionStatus object in its body. | 0 | 0 | 2 | 2 | ||
| 89: http-basic-profile-protocol-binding-cancelaction-3 | Consumer | Y | In order to cancel an action request, a Consumer MUST send an HTTP request to a Web Thing with: Method set to DELETE URL set to the URL of the ActionStatus resource | 0 | 0 | 2 | 2 | ||
| 90: http-basic-profile-protocol-binding-cancelaction-5 | Thing | Y | If a Web Thing receives an HTTP request following the format above and the Consumer has permission to cancel the corresponding Action request, then upon successfully cancelling Action it MUST send an HTTP response with: Status code set to 204 | 3 | 0 | 1 | 4 | ||
| 91: http-basic-profile-protocol-binding-queryallactions-1 | Consumer | Y | The URL of an Actions resource to be used when querying the status of all ongoing action requests MUST be obtained from a Thing Description by locating a Form inside the top level forms member for which: Its op member contains the value queryallactions After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https | 0 | 0 | 2 | 2 | ||
| 92: http-basic-profile-protocol-binding-queryallactions-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Actions resource. | 0 | 0 | 2 | 2 | ||
| 93: http-basic-profile-protocol-binding-queryallactions-4 | Consumer | Y | In order to query the status of all ongoing action requests, a Consumer MUST send an HTTP request to a Web Thing with: Method set to GET URL set to the URL of the Actions resource Accept header set to application/json | 0 | 0 | 2 | 2 | ||
| 94: http-basic-profile-protocol-binding-queryallactions-6a | Thing | Y | If a Web Thing receives an HTTP request following the format above, then upon successfully retreiving the status of all ongoing action requests to which the Consumer has permission to access, it MUST send an HTTP response with: Status code set to 200 Content-Type header set to application/json A body containing an object, keyed by Action name, with the value of each object member being an array of ActionStatus objects representing the action requests, serialized in JSON. | 1 | 0 | 3 | 4 | ||
| 95: http-basic-profile-protocol-binding-queryallactions-6b | Thing | Y | Each array in the result object MUST be sorted in reverse chronological order such that the most recent action request appears first. | 0 | 1 | 3 | 4 | ||
| 96: http-sse-profile-1 | Thing Consumer TD | Y | In order to conform with the HTTP SSE Profile, Web Things and Consumers MUST also conform with all of the assertions in the Common Constraints section. | 2 | 1 | 2 | 5 | ||
| 97: http-sse-profile-identifier-1 | TD | Y | In order to denote that a given Web Thing conforms to the HTTP SSE Profile, its Thing Description MUST have a profile member [[wot-thing-description]] with a value of https://www.w3.org/2022/wot/profile/http-sse/v1. | 2 | 0 | 2 | 4 | ||
| 98: http-sse-profile-protocol-binding-1 | Consumer Thing | Y | A Consumer or Web Thing conforming to the HTTP SSE Profile MUST implement this protocol binding. | 3 | 0 | 2 | 5 | ||
| 99: http-sse-profile-protocol-binding-observeproperty-1 | Consumer | Y | The URL of a Property resource to be used when observing the value of a property MUST be obtained from a Thing Description by locating a Form inside the corresponding PropertyAffordance for which: Its op member contains the value observeproperty After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https Its subprotocol member has a value of sse | 2 | 0 | 1 | 3 | ||
| 100: http-sse-profile-protocol-binding-observeproperty-2 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Property resource. | 2 | 0 | 1 | 3 | ||
| 101: http-sse-profile-protocol-binding-observeproperty-3 | Consumer | Y | In order to observe a property, a Consumer MUST follow the Server-Sent Events [[EVENTSOURCE]] specification to open a connection with the Web Thing at the URL of the Property resource. | 1 | 0 | 2 | 3 | ||
| 102: http-sse-profile-protocol-binding-observeproperty-4 | Thing | Y | If a Web Thing receives an HTTP request following the format above and the Consumer has permission to observe the corresponding property, then it MUST follow the Server-Sent Events [[EVENTSOURCE]] specification to maintain an open connection with the Consumer and push a property value to the Consumer each time the value of the specified property changes. | 1 | 0 | 2 | 3 | ||
| 103: http-sse-profile-protocol-binding-observeproperty-5a | Thing | Y | Whenever the value of the specified property changes while the Web Thing has an open connection with a Consumer, the Web Thing MUST send a property value to the Consumer using the event stream format in the Server-Sent Events [[EVENTSOURCE]] specification. | 2 | 0 | 1 | 3 | ||
| 104: http-sse-profile-protocol-binding-observeproperty-5b | Thing | Y | For each message sent, the Web Thing MUST set the event field to the name of the PropertyAffordance and populate the data field with the property value, serialized in JSON and following the data schema specified in the PropertyAffordance. | 2 | 0 | 1 | 3 | ||
| 105: http-sse-profile-protocol-binding-observeproperty-5c | Thing | N | The id field SHOULD be set to a unique identifier for the property change, for use when re-establishing a dropped connection (see below). | 2 | 0 | 1 | 3 | ||
| 106: http-sse-profile-protocol-binding-observeproperty-5d | Thing | N | It is RECOMMENDED that the identifier is a timestamp representing the time at which the property changed | 2 | 0 | 1 | 3 | ||
| 107: http-sse-profile-protocol-binding-observeproperty-6a | Consumer | Y | If the connection between the Consumer and Web Thing drops (except as a result of the unobserve operation defined below), the Consumer MUST re-establish the connection following the steps outlined in the Server-Sent Events specification [[EVENTSOURCE]]. | 1 | 0 | 2 | 3 | ||
| 108: http-sse-profile-protocol-binding-observeproperty-6b | Thing | N | Once the connection is re-established the Web Thing SHOULD, if possible, send any missed property changes which occurred since the last change specified by the Consumer in a Last-Event-ID header. | 0 | 1 | 2 | 3 | ||
| 109: http-sse-profile-protocol-binding-unobserveproperty-1 | Consumer | Y | In order to stop observing a property, a Consumer MUST terminate the corresponding Server-Sent Events connection with the Web Thing as specified in the Server-Sent Events specification [[EVENTSOURCE]]. | 2 | 0 | 1 | 3 | ||
| 110: http-sse-profile-protocol-binding-observeallproperties-1 | Consumer TD | Y | The URL of a properties resource to be used when observing changes to all properties of a Web Thing MUST be obtained from a Thing Description by locating a Form inside the top level forms member of a Thing Description for which: Its op member contains the value observeallproperties After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https Its subprotocol member has a value of sse | 0 | 0 | 1 | 1 | ||
| 111: http-sse-profile-protocol-binding-observeallproperties-2 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the properties resource. | 0 | 0 | 1 | 1 | ||
| 112: http-sse-profile-protocol-binding-observeallproperties-3 | Consumer | Y | In order to observe changes to all properties of a Web Thing, a Consumer MUST follow the Server-Sent Events [[EVENTSOURCE]] specification to open a connection with the Web Thing at the URL of the properties resource. | 0 | 0 | 1 | 1 | ||
| 113: http-sse-profile-protocol-binding-observeallproperties-4 | Thing | Y | If a Web Thing receives an HTTP request following the format above then it MUST follow the Server-Sent Events [[EVENTSOURCE]] specification to maintain an open connection with the Consumer and push new property values to the Consumer for all properties for which it has permission to observe. | 1 | 0 | 1 | 2 | ||
| 114: http-sse-profile-protocol-binding-observeallproperties-5a | Thing | Y | Whenever a property changes while the Web Thing has an open connection with a Consumer, the Web Thing MUST send the new property value to the Consumer using the event stream format in the Server-Sent Events [[EVENTSOURCE]] specification. | 1 | 0 | 1 | 2 | ||
| 115: http-sse-profile-protocol-binding-observeallproperties-5b | Thing | Y | For each message sent, the Web Thing MUST set the event field to the name of the PropertyAffordance and populate the data field with the new property value. | 1 | 0 | 1 | 2 | ||
| 116: http-sse-profile-protocol-binding-observeallproperties-5c | Thing | Y | The property data MUST follow the data schema specified in the PropertyAffordance and MUST be serialized in JSON. | 1 | 0 | 1 | 2 | ||
| 117: http-sse-profile-protocol-binding-observeallproperties-5d | Thing | N | The id field SHOULD be set to a unique identifier for the event, for use when re-establishing a dropped connection (see below). | 1 | 0 | 1 | 2 | ||
| 118: http-sse-profile-protocol-binding-observeallproperties-5e | Thing | N | It is RECOMMENDED that the identifier is a timestamp representing the time at which the property changed | 1 | 0 | 1 | 2 | ||
| 119: http-sse-profile-protocol-binding-observeallproperties-6a | Consumer | Y | If the connection between the Consumer and Web Thing drops (except as a result of the unobserveallproperties operation defined below), the Consumer MUST re-establish the connection following the steps outlined in the Server-Sent Events specification [[EVENTSOURCE]]. | 0 | 0 | 1 | 1 | ||
| 120: http-sse-profile-protocol-binding-observeallproperties-6b | Thing | N | Once the connection is re-established the Web Thing SHOULD, if possible, send any missed property changes which occurred since the last change specified by the Consumer in a Last-Event-ID header. | 0 | 1 | 1 | 2 | ||
| 121: http-sse-profile-protocol-binding-unobserveallproperties-1 | Consumer | Y | In order to unobserve all properties, a Consumer MUST terminate the corresponding Server-Sent Events connection with the properties endpoint of the Web Thing, following the steps specified in the Server-Sent Events specification [[EVENTSOURCE]]. | 0 | 0 | 1 | 1 | ||
| 122: http-sse-profile-protocol-binding-subscribeevent-1 | Consumer | Y | The URL of an Event resource to be used when subscribing to an event MUST be obtained from a Thing Description by locating a Form inside the corresponding EventAffordance for which: After defaults have been applied, its op member contains the value subscribeevent After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https Its subprotocol member has a value of sse | 1 | 0 | 1 | 2 | ||
| 123: http-sse-profile-protocol-binding-subscribeevent-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Event resource. | 1 | 0 | 1 | 2 | ||
| 124: http-sse-profile-protocol-binding-subscribeevent-4 | Consumer | Y | In order to subscribe to an event, a Consumer MUST follow the Server-Sent Events [[EVENTSOURCE]] specification to open a connection with the Web Thing at the URL of the Event resource. | 0 | 0 | 2 | 2 | ||
| 125: http-sse-profile-protocol-binding-subscribeevent-5 | Thing | Y | If a Web Thing receives an HTTP request following the format above and the Consumer has permission to subscribe to the corresponding event, then it MUST follow the Server-Sent Events [[EVENTSOURCE]] specification to maintain an open connection with the Consumer and push event data to the Consumer as events of the specified type are emitted. | 2 | 0 | 1 | 3 | ||
| 126: http-sse-profile-protocol-binding-subscribeevent-6a | Thing | Y | Whenever an event of the specified type occurs while the Web Thing has an open connection with a Consumer, the Web Thing MUST send event data to the Consumer using the event stream format in the Server-Sent Events [[EVENTSOURCE]] specification. | 2 | 0 | 1 | 3 | ||
| 127: http-sse-profile-protocol-binding-subscribeevent-6b | Thing | Y | For each message sent, the Web Thing MUST set the event field to the name of the EventAffordance and populate the data field with event data, if any. | 2 | 0 | 1 | 3 | ||
| 128: http-sse-profile-protocol-binding-subscribeevent-6c | Thing | Y | The event data MUST follow the data schema specified in the EventAffordance and be serialized in JSON. | 2 | 0 | 1 | 3 | ||
| 129: http-sse-profile-protocol-binding-subscribeevent-6d | Thing | N | The id field SHOULD be set to a unique identifier for the event, for use when re-establishing a dropped connection (see below). | 1 | 0 | 2 | 3 | ||
| 130: http-sse-profile-protocol-binding-subscribeevent-6e | Thing | N | It is RECOMMENDED that the identifier is a timestamp representing the time at which the event ocurred | 1 | 0 | 2 | 3 | ||
| 131: http-sse-profile-protocol-binding-subscribeevent-7a | Consumer | Y | If the connection between the Consumer and Web Thing drops (except as a result of the unsubscribeevent operation defined below), the Consumer MUST re-establish the connection following the steps outlined in the Server-Sent Events specification [[EVENTSOURCE]]. | 0 | 0 | 2 | 2 | ||
| 132: http-sse-profile-protocol-binding-subscribeevent-7b | Thing | N | Once the connection is re-established the Web Thing SHOULD, if possible, send any missed events which occurred since the last event specified by the Consumer in a Last-Event-ID header. | 0 | 1 | 2 | 3 | ||
| 133: http-sse-profile-protocol-binding-unsubscribeevent-1 | Consumer | Y | In order to unsubscribe from an event, a Consumer MUST terminate the corresponding Server-Sent Events connection with the Web Thing as specified in the Server-Sent Events specification [[EVENTSOURCE]]. | 1 | 0 | 1 | 2 | ||
| 134: http-sse-profile-protocol-binding-subscribeallevents-1 | Consumer | Y | The URL of an events resource to be used when subscribing to all events emitted by a Web Thing MUST be obtained from a Thing Description by locating a Form inside the top level forms member of a Thing Description for which: Its op member contains the value subscribeallevents After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https Its subprotocol member has a value of sse | 0 | 0 | 1 | 1 | ||
| 135: http-sse-profile-protocol-binding-subscribeallevents-3b | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the events resource. | 0 | 0 | 1 | 1 | ||
| 136: http-sse-profile-protocol-binding-subscribeallevents-4 | Consumer | Y | In order to subscribe to all events emitted by a Web Thing, a Consumer MUST follow the Server-Sent Events [[EVENTSOURCE]] specification to open a connection with the Web Thing at the URL of the events resource. | 0 | 0 | 1 | 1 | ||
| 137: http-sse-profile-protocol-binding-subscribeallevents-3 | Thing | Y | If a Web Thing receives an HTTP request following the format above then it MUST follow the Server-Sent Events [[EVENTSOURCE]] specification to maintain an open connection with the Consumer and push event data to the Consumer for all event types for which it has permission to subscribe. | 1 | 0 | 1 | 2 | ||
| 138: http-sse-profile-protocol-binding-subscribeallevents-4a | Thing | Y | Whenever an event occurs while the Web Thing has an open connection with a Consumer, the Web Thing MUST send event data to the Consumer using the event stream format in the Server-Sent Events [[EVENTSOURCE]] specification. | 1 | 0 | 1 | 2 | ||
| 139: http-sse-profile-protocol-binding-subscribeallevents-4b | Thing | Y | For each message sent, the Web Thing MUST set the event field to the name of the EventAffordance and populate the data field with event data, if any. | 1 | 0 | 1 | 2 | ||
| 140: http-sse-profile-protocol-binding-subscribeallevents-4c | Thing | Y | The event data MUST follow the data schema specified in the EventAffordance and be serialized in JSON. | 1 | 0 | 1 | 2 | ||
| 141: http-sse-profile-protocol-binding-subscribeallevents-4d | Thing | N | The id field SHOULD be set to a unique identifier for the event, for use when re-establishing a dropped connection (see below). | 1 | 0 | 1 | 2 | ||
| 142: http-sse-profile-protocol-binding-subscribeallevents-4e | Thing | N | It is RECOMMENDED that the identifier is a timestamp representing the time at which the event ocurred | 1 | 0 | 1 | 2 | ||
| 143: http-sse-profile-protocol-binding-subscribeallevents-5a | Consumer | Y | If the connection between the Consumer and Web Thing drops (except as a result of the unsubscribeallevents operation defined below), the Consumer MUST re-establish the connection following the steps outlined in the Server-Sent Events specification [[EVENTSOURCE]]. | 0 | 0 | 1 | 1 | ||
| 144: http-sse-profile-protocol-binding-subscribeallevents-5b | Thing | N | Once the connection is re-established the Web Thing SHOULD, if possible, send any missed events which occurred since the last event specified by the Consumer in a Last-Event-ID header. | 0 | 1 | 1 | 2 | ||
| 145: http-sse-profile-protocol-binding-unsubscribeallevents-1 | Consumer | Y | In order to unsubscribe from all events, a Consumer MUST terminate the corresponding Server-Sent Events connection with the events endpoint of the Web Thing, following the steps specified in the Server-Sent Events specification [[EVENTSOURCE]]. | 0 | 0 | 1 | 1 | ||
| 146: http-webhook-profile-protocol-binding-general-1 | Consumer Thing | N | The HTTP Webhook profile MAY be used in conjunction with the HTTP Basic Profile in order to provide operations to read and write properties and invoke, query and cancel actions. | 1 | 0 | 0 | 1 | ||
| 147: http-webhook-profile-protocol-binding-general-3 | Consumer Thing | Y | In order to conform with the HTTP Webhook Profile, Web Things and Consumers MUST also conform with all of the assertions in the Common Constraints section. | 1 | 0 | 0 | 1 | ||
| 148: http-webhook-profile-protocol-binding-events-1 | Consumer Thing | N | Depending on the use case, a single listener for multiple things and multiple endpoints MAY be used. | 1 | 0 | 0 | 1 | ||
| 149: http-webhook-profile-protocol-binding-events-2 | Consumer | N | To minimize network traffic, the same Consumer SHOULD NOT perform multiple subscriptions to the same endpoint. | 0 | 0 | 0 | 0 | ||
| 150: http-webhook-profile-1 | TD | Y | In order to denote that a given Web Thing conforms to the HTTP Webhook Profile, its Thing Description MUST have a profile member [[wot-thing-description]] with a value of https://www.w3.org/2022/wot/profile/http-webhook/v1. | 1 | 0 | 0 | 1 | ||
| 152: http-webhook-profile-protocol-binding-1 | Consumer Thing TD | Y | A Consumer or Web Thing conforming to the HTTP Webhook Profile MUST implement this protocol binding. | 0 | 0 | 0 | 0 | ||
| 172: http-basic-profile-protocol-binding-subscribeevent-1 | Consumer | Y | The URL of an Event resource to be used when subscribing to an event MUST be obtained from a Thing Description by locating a Form inside the corresponding EventAffordance for which: After defaults have been applied, its op member contains the value subscribeevent After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https Its Content-Type header has a value of application/json Its subprotocol member has a value of webhook | 0 | 0 | 0 | 0 | ||
| 173: http-webhook-profile-protocol-binding-subscribeevent-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the Event resource. | 0 | 0 | 0 | 0 | ||
| 174: http-webhook-profile-protocol-binding-subscribeevent-4 | Consumer | Y | In order to subscribe to an event, a Consumer MUST provide the listener URL in the request payload of the subscribeevent operation of the Event resource. | 0 | 0 | 0 | 0 | ||
| 176: http-webhook-profile-protocol-binding-subscribeevent-6 | Thing | Y | Whenever an event of the specified type occurs, the Web Thing MUST send event notifications to the Consumer using the event payload format defined in section ["#http-webhook-profile-protocol-binding-notification-format"]. | 1 | 0 | 0 | 1 | ||
| 179: http-webhook-profile-protocol-binding-subscribeallevents-1 | Consumer | Y | The URL of an Events resource to be used when subscribing to all events emitted by a Web Thing MUST be obtained from a Thing Description by locating a Form inside the top level forms member of a Thing Description for which: Its op member contains the value subscribeallevents After being resolved against a base URL where applicable, the URI scheme [[RFC3986]] of the value of its href member is http or https Its Content-Type header has a value of application/json Its subprotocol member has a value of webhook | 0 | 0 | 0 | 0 | ||
| 180: http-webhook-profile-protocol-binding-subscribeallevents-3 | Consumer | Y | The resolved value of the href member MUST then be used as the URL of the events resource. | 0 | 0 | 0 | 0 | ||
| 181: http-webhook-profile-protocol-binding-subscribeallevents-4 | Consumer | Y | In order to subscribe to all events emitted by a Web Thing, a Consumer MUST send an HTTP request to the Web Thing with: Method set to POST URL set to the URL of the events resource Content-Type header set to application/json Request Payload contains a JSON object with a subscription request payload. | 0 | 0 | 0 | 0 | ||
| 182: http-webhook-profile-protocol-binding-subscribeallevents-5 | Thing | Y | If a Web Thing receives an HTTP request following the format above, then it MUST send event messages to the Consumer for all event types for which it has permission to subscribe. | 1 | 0 | 0 | 1 | ||
| 183: http-webhook-profile-protocol-binding-subscribeallevents-6 | Thing TD | Y | Whenever an event occurs, the Web Thing MUST send event data to the Consumer using the event payload format defined in section Notification Format. | 0 | 0 | 0 | 0 | ||
| 184: http-webhook-profile-protocol-binding-unsubscribeallevents-1 | Consumer | Y | In order to unsubscribe from all events, a Consumer MUST invoke the unsubscribeevent operation of the Event resource. | 0 | 0 | 0 | 0 | ||
| 186: http-webhook-profile-protocol-binding-event-connections-1 | Thing | Y | An HTTP(s) connection to the notification listener of a Consumer MUST be initiated and managed by the Web Thing. | 1 | 0 | 0 | 1 | ||
| 188: http-webhook-profile-protocol-binding-event-connections-2 | Consumer | Y | A Consumer MUST actively terminate the subscription with the event or property endpoint that is sending notifications of the Web Thing. | 0 | 0 | 0 | 0 | ||
| 189: http-webhook-profile-protocol-binding-event-connections-3 | Thing | N | If a Consumer becomes unavailable and the Web Thing cannot successfully transmit notification messages to the consumer, it SHOULD attempt several retries at increasing intervals. | 0 | 0 | 1 | 1 | ||
| 190: http-webhook-profile-protocol-binding-event-connections-4 | Thing | N | After the maximum number of retries was reached, the Web Thing MAY terminate the subscription without having received an explicit request corresponding to an unsubscribe or unsubscribeall operation. | 0 | 0 | 1 | 1 | ||
| 191: http-webhook-profile-protocol-binding--event-connections-8 | Consumer | Y | When a notification message has been received, the Consumer MUST respond with an HTTP 200 OK response code, if the response contains a body. | 0 | 0 | 0 | 0 | ||
| 193: http-webhook-profile-protocol-binding-event-connections-9 | Consumer TD | N | An (optional) JSON payload MAY be provided to return a response back to the Web Thing via the same communication channel. | 0 | 0 | 0 | 0 | ||
| 194: privacy-considerations-1 | Consumer Thing TD | Y | The privacy considerations of the WoT Architecture and WoT Thing Description MUST be adopted by compliant implementations. | 0 | 0 | 0 | 0 | ||
| 195: security-considerations-1 | Consumer Thing TD | Y | The security considerations of the WoT Architecture and WoT Thing Description MUST be adopted by compliant implementations. | 0 | 0 | 0 | 0 | ||
The Web of Things Working Group would like to acknowledge the contributions to the making of this document from the following individuals in various capacities.