Open thjaeckle opened 3 years ago
To my understanding the following:
The event binding is identical for both HTTP request and response messages.
Simply states that the cloud event binding for HTTP can be used the same way for request and response. However there is no requirement that the endpoint must response with a cloud event.
Taking a look at the example code from cloudevents seems to confirm this:
However, I think it may make sense for Ditto to respond with something other than "ok, I processed the event". If Ditto can provide additional information, as the outcome of the operation, then it could provide this.
I am not sure how the Accept
header fits into the picture. I don't think the header is used by the cloud events spec. And so I don't think Ditto should introduce a new concept, which is not covered by the HTTP cloud events mapping.
The cloudevents endpoint cannot support query, message and search commands without responses. I'm fine with not supporting those, especially search commands where additional session management would be necessary, but the error message should probably be clearer than "Query commands must not have the header 'response-required' set to 'false'".
Currently with #889 and #895 the
/cloudevents
POST endpoint acts as "sink" only:However, no response payload in "Ditto Protocol JSON" is returned. The cloud event spec for HTTP defines:
IMO the route's response behavior has to be adjusted:
Accept
HTTP header and applying content negotiation