Interactions-HSG / wot-td-java

A Java library for the W3C WoT Thing Description: https://www.w3.org/TR/wot-thing-description/
Other
8 stars 7 forks source link

Create a common interface for protocol bindings #72

Open vcharpenay opened 2 years ago

vcharpenay commented 2 years ago

Currently, it seems that WoT consumers have to know in advance the protocol binding of a Thing. If a Thing has both an HTTP and a CoAP binding, a consumer has to decide statically whether to instantiate a TDHttpRequest or a TDCoapRequest from each form.

Would it be possible to instantiate a generic object representing a request (or, in the WoT terminology, an operation)? Here is a suggestion:

Optional<PropertyAffordance> humidity = td.getPropertyByName("humidity");

if (humidity.isPresent()) {
  Optional<Form> form = humidity.get().getFirstFormForOperationType(TD.readProperty);

  if(form.isPresent()) {
    // here is the proposal
    Operation op = ProtocolBindingFactory.bind(form.get(), TD.readProperty);
    op.setPayload();
    Response response = op.execute();

    // the response's interface is generic, it may include properties of the Expected Response class and a 'payload' property represented as JSON, as current TDHttpResponse objects
  }
}

Protocol bindings may register themselves to ProtocolBindingFactory.

vcharpenay commented 2 years ago

Currently, a TD that has forms with unknown bindings cannot be read, because of an exception thrown by TDGraphReader (l. 335). Yet, as it is currently designed, the lib may already be used by external code (that would provide more bindings than HTTP or CoAP).

Could that behavior be relaxed?

vcharpenay commented 2 years ago

See on-going development in this direction at Hypermedea/wot-td-java.