Re: External communication with SCXML

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