- From: <Pierre.Wellner@inficon.com>
- Date: Mon, 11 Feb 2013 18:01:23 -0500
- To: www-voice@w3.org
- Message-ID: <OFA4411264.A416920F-ON85257B0F.006B8330-85257B0F.007E9B1A@inficon.com>
Hello Stephan, We communicate in and out of SCXML over HTTP, but do not use a strict REST design, because SCXML doesn't seem to provide a clear way to specify the HTTP method, which REST needs. We send SCXML events from <send> as a simple JSON object in the body of POST requests, and if a JSON object appears in the response we process it in the sending SCXML session. Our JSON structure is based on SCXML's _event variable, so it must have a "name" property, and may also have "data", "target", and "origin" properties. Although it's easy to POST these events from JavaScript in a web browser, as a convenience we also define a URL string format for simple events that can be typed in a browser address bar and sent as HTTP GET requests. For example in the following URL: http://localhost:8899/targetName/sys.abort?code=27&severity=red the final segment of the path (between the last "/" and the "?") is the event name, so a GET of the example above is equivalent to a POST of the JSON string {"name":"sys.abort", "data":{"code":27,"severity":"red"}} to the target http://localhost:8899/targetName If missing, the "target" and "origin" properties are set to suitable defaults by the SCXML interpreter's environment so that we can reply with something like <send event="replyEvent" targetexpr="_event.origin" /> This approach provides familiar-looking APIs to developers used to REST, and we have extended it to handle publish and subscribe. But it will not satisfy the REST purists. Best regards, Pierre -------------------------------------------------------------------------------------------------- From: Stefan Radomski <radomski@tk.informatik.tu-darmstadt.de> Date: Mon, 11 Feb 2013 17:42:30 +0000 To: "www-voice@w3.org (www-voice@w3.org)" <www-voice@w3.org> Message-ID: <6A775895400B8040A331C2963964820C19535FEB@exchange01.tk.informatik.tu-darmstadt.> Hi again, we are about to implement a simple REST interface (in & out) and were pondering about the best way to integrate such a thing into SCXML's concepts. There already is the basichttp ioprocessor available for the type attribute with send, but - as I raised earlier - it will completely ignore the actual result of such a request. One possibility would be to go for a "resthttp" (or similar) type which could deliver the result as an event into the interpreter. This would solve sending requests via SCXML and get at their result. As for receiving requests, we need to get them as an event (just as with the basichttp ioprocessor) and be able to reply. Replying could be realized by sending an event to a special #_http.requestId but I'd like to gather some thoughts first. Another alternative is to go for a dedicated invoker that will deliver events and is available to reply to the remote party. I understand that all of this can be solved "out-of-draft" but then again, maybe the various implementations could at least provide common concepts. Anyone have some thoughts about this? Best regards Stefan
Received on Monday, 11 February 2013 23:03:05 UTC