Specify error message format

[benfrancis]

5.2.5.1 MUST define a standardised format for sending error messages to a WoT Consumer when an operation is not successful

5.2.5.2 SHOULD define common error responses for all operations on a Web Thing

[benfrancis]

Proposal from #42

Error Response

{
  "thingID": "https://mythingserver.com/things/mylamp1",
  "messageID": "79057736-3e0e-4dc3-b139-a33051901ee2",
  "messageType": "response",
  "operation": "readproperty",
  "name": "on",
  "error": {
    "status": "404",
    "type": "https://w3c.github.io/web-thing-protocol/errors#not-found",
    "title": "Not Found"
    "detail": "No property found with the name 'on'"
  }
  "timestamp": "2024-01-13T23:20:50.52Z",
  "correlationID": "5afb752f-8be0-4a3c-8108-1327a6009cbd"
}

[egekorkan]

I think that error types can be aligned with Scripting API. The current references in it point to ecmascript spec.

What do you think @relu91 @danielpeintner ?

[danielpeintner]

We have (had) a long discussion in w3c/wot-scripting-api#200

Yes, I definitely agree that error types should be aligned. On the other hand, it is difficult to have (or prescribe) a set of error types and error codes for bindings we don't know and may go beyond HTTP/JS error types.

[relu91]

I agree to strive for an alignment between the two, when it is possible, and I'd like to receive some feedback about the errors we defined.

I think the issue is more about the on-wire format, which I think is good. Is it Problem Details (RFC 7807)right?

[benfrancis]

@relu91

I think the issue is more about the on-wire format, which I think is good. Is it Problem Details (RFC 7807)right?

Yes, in the Strawman Proposal it enforces Problem Details format, which is intended to be consistent with WoT Profiles.

To be honest Problem Details format is kind of optimised for HTTP, so may sometimes feel a bit strange in the context of a WebSocket sub-protocol, but I do think it's useful.

I think scripting errors (like those you'd get when catching a JavaScript exception) are a bit different to protocol errors (like those you'd get in an HTTP response). There may be some correlation with errors like NotFoundError (404 Not Found) and NotSupportedError (501 Not Implemented), but I'm not sure there will be a 1:1 mapping, and there may be subtle differences in meaning.

My instinct is that protocol errors are always going to require some level of translation to turn them into protocol-agnostic scripting errors.

Problem Details Format assigns URIs to error types, so what I do think would be helpful would be to have a shared set of error types between WoT Profiles (or possibly binding templates?) and the Web Thing Protocol. So far the Profiles specification recommends a particular set of HTTP error codes and requires that if there is a body in an error response that it must follow the Problem Details format, but it doesn't yet go as far as defining particular error types with URIs as identifiers.

[relu91]

I think scripting errors (like those you'd get when catching a JavaScript exception) are a bit different to protocol errors (like those you'd get in an HTTP response). There may be some correlation with errors like NotFoundError (404 Not Found) and NotSupportedError (501 Not Implemented), but I'm not sure there will be a 1:1 mapping, and there may be subtle differences in meaning.

My instinct is that protocol errors are always going to require some level of translation to turn them into protocol-agnostic scripting errors.

Yes, that's what I meant by "when it is possible".

Problem Details Format assigns URIs to error types, so what I do think would be helpful would be to have a shared set of error types between WoT Profiles (or possibly binding templates?) and the Web Thing Protocol. So far, the Profiles specification recommends a particular set of HTTP error codes and requires that if there is a body in an error response that it must follow the Problem Details format, but it doesn't yet go as far as defining particular error types with URIs as identifiers.

Maybe Web Thing Protocol should define a set of types and THEN Profiles recommend using those?