RESTful -> WAMP Bridge

[Mauro Condarelli]

Hi,
I'm new to WAMP and a bit confused, please help me understand.

I am pushing for adoption of WAMP in our current RESTful-based environment.

I understand there is some kind of RESTful -> WAMP bridge, but it's unclear to me how powerful it is and where can I find further information.

In particular I have the need to provide a "true" RESTful API (at least for POST and GET); it means I need to be able to make such request with all parameters in the URL itself, without need to format a JSon packet (of course I will need to parse the returning JSon). Is this supported by Crossbar (or some other add-on)? If so: how? Otherwise I will have to provide some kind of front-end... which would defy most o WAMP usefulness.

Can someone point me in the right direction, please?
Regards
Mauro

[Alexander Gödde]

Hi Mauro!

The documentation for the HTTP bridge services is at http://crossbar.io/docs/HTTP-Bridge/

http://crossbar.io/docs/HTTP-Bridge/

Let us know whether this fits your requirements.

Regards,

Alex

[Mauro Condarelli]

Thanks Alexander,
I already saw that, but it seems a generic HTTP -> WAMP bridge, while I need a full RESTful -> WAMP.
Did I miss some important clue?

What I need is to be able to use something like:
  GET http://my.server.org/RESTful/customer/12345
  PUT http://my.server.org/RESTful/customer/12345?discount=30

which should be automagically translated in something like:
  { "procedure" : "org.server.my.GET.customer", "args" : [ 12345 ] }
  { "procedure" : "org.server.my.PUT.customer", "args" : [ 12345, { "discount": "30 } ] }

Is something like that available somewhere?

If not I will have to implement something; what is the advised way to do it?
Should I use CGI capabilities of Crossbar?
Use an external Web server? (nginx?)

Any comment welcome
TiA
Mauro

[Johnny W. Santos]

Hi Mauro,

There is some examples here https://github.com/crossbario/crossbarexamples/tree/master/rest

--
You received this message because you are subscribed to the Google Groups "Crossbar" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crossbario+...@googlegroups.com.
To post to this group, send email to cross...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/04d34b2a-29cb-414f-ba7a-610e916401a1%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Johnny W. dos Santos

[Mauro Condarelli]

Thanks Johnny,
unfortunately we are always on the same page.

What seems to be available is a HTTP POST to WAMP bridge.
This is very far from a RESTful API, at least on my book.

What I need is a set of requests completely contained in the URI with no JSon at all and using several different requests (at least GET, PUT, POST and DELETE).
JSon should be used only in the answer string.

In all examples I saw curl used to POST a JSon string containing the data.
Unless I'm missing some very important point this is pretty useless to me.

Next question thus is: If I want to implement such an "enhancement" what is the advised way?
(note: I am not proficient in Python, unfortunately)

TiA
Mauro

[Johnny W. Santos]

What WAMP HTTP Bridge does is expose the WMAP goodies through a REST interface.

[Tobias Oberstein]

A RESTful flavor of the HTTP bridge we have would be neat, and naturally building on the existing HTTP bridge code while using a different URL mapping, HTTP methods, headers and payload. Also, I don't see how to expose more complex arguments without using payload, such as JSON encoded values. With empty payload, everything more complex than a set of named scalar parameters encoded as HTTP request query parameters seems painful. @hawkowl

Sent from Mobile (Google Nexus 5)

To view this discussion on the web visit https://groups.google.com/d/msgid/crossbario/3bd917c8-187b-4fc1-9977-cf78efa4a88c%40googlegroups.com.

[Elvis Stansvik]

2015-11-20 21:10 GMT+01:00 Tobias Oberstein <tobias.o...@gmail.com>:
> A RESTful flavor of the HTTP bridge we have would be neat, and naturally
> building on the existing HTTP bridge code while using a different URL
> mapping, HTTP methods, headers and payload. Also, I don't see how to expose
> more complex arguments without using payload, such as JSON encoded values.
> With empty payload, everything more complex than a set of named scalar
> parameters encoded as HTTP request query parameters seems painful. @hawkowl

I also don't really see how WAMP could be mapped to a RESTful API and
the various request methods in a general way. Part of designing your
RESTful API is precisely to design this URL/method mapping to your
specific problem domain.

But Mauro, even if you don't have much experience in Python, I think
it should be possible to just use some light micro webframework like
Flask or something, and build your own RESTful -> Crossbar HTTP bridge
bridge (yes, two bridges :)).

Cheers,
Elvis

> https://groups.google.com/d/msgid/crossbario/CABuE%2BY7YL%2BSPugPL2yn1bTT3FN7GBGxOmT%2BFo4FLATYFYF9o8w%40mail.gmail.com.

[Elvis Stansvik]

2015-11-20 21:47 GMT+01:00 Elvis Stansvik <elvs...@gmail.com>:
> 2015-11-20 21:10 GMT+01:00 Tobias Oberstein <tobias.o...@gmail.com>:
>> A RESTful flavor of the HTTP bridge we have would be neat, and naturally
>> building on the existing HTTP bridge code while using a different URL
>> mapping, HTTP methods, headers and payload. Also, I don't see how to expose
>> more complex arguments without using payload, such as JSON encoded values.
>> With empty payload, everything more complex than a set of named scalar
>> parameters encoded as HTTP request query parameters seems painful. @hawkowl
>
> I also don't really see how WAMP could be mapped to a RESTful API and

Sorry I meant "a RESTful API could be mapped to WAMP" above, but you
get what I mean :)

Elvis

[Mauro Condarelli]

Hi Tobias,
thanks for Your answer.

I am fully aware we cannot encode everything in URIs, but there's a good deal of functionality that can be trivially encoded.

First candidate for "RESTful-ization" is obviously the RPC section of WAMP (RESTful does not really define a push interface).

My first attempt (probably misguided, since I'm not a WEB guru) would be to map URI to JSon with the following scheme:

1) remove the header, up to a conventional component (e.g.: "RESTful").
2) add request type to function name, followed by a dot ('.')
3) map all "path" components to function name substituting a dot ('.') for each delimiter (usually '/')
4) add last component of "path" as first argument.
5) for each "query" component:
5.1) if it is naked (no '=') then add it as an argument
5.2) if it is qualified (with '=') the add it as a subcomponent '{ "key" : "value" }'
5.3) double separators are special:
5.3.1) ';&' starts a subcomponent ('{')
5.3.2) ';;' ends a subcomponent ('}')
5.3.3) '&&' starts an array ('[')
5.3.4) '&;' ends an array (']')
5.4) "fragment" is a JSon string and it is appended as-is
5.5) any subcomponents or arrays still open are closed to form a "legitimate" JSon fragment.

Example:

URI:     GET http://my.server.org/RESTful/customer/12345
JSon:   { "procedure" : "GET.customer", "args" : [ 12345 ] }

URI:     PUT http://my.server.org/RESTful/customer/12345?discount=30
JSon:   { "procedure" : "PUT.customer", "args" : [ 12345, { "discount": "30 } ] }

URI:     GET http://my.server.org/RESTful/customer/12345?discount
JSon:   { "procedure" : "PUT.customer", "args" : [ 12345, "discount" ] }

URI:     GET http://my.server.org/RESTful/customer/12345/discount
JSon:   { "procedure" : "PUT.customer.12345", "args" : [ "discount" ] } (probably useless!)

URI:     GET http://my.server.org/RESTful/customer/discount/12345
JSon:   { "procedure" : "PUT.customer.discount", "args" : [ "12345" ] } (better semantic)

URI:     GET http://my.server.org/RESTful/customer/discount/#{my:[horribly, complex, {json:string}, {badly:terminated
JSon:   { "procedure" : "PUT.customer.discount", "args" : [ "my" : { "horribly", "complex", { "json" : "string" }, { "badly" : "terminated" } ] } (... if I didn't make any stupid typos ;) )

This scheme (or something similar) allows to encode arbitrary JSon fragments and the real limit is how much we want to make complex the URI.
I do expect people to encode this way simple things and to fall back to currently available schemes (i.e.: direct JSon encoding) when the URI becomes too cumbersome.

Did I forget something?
Do You thing this is feasible?
If so: what is the best implementation path?

Thanks
Mauro