OK, its been a while since we started to look into using the REST web services plug-in. We briefly looked at the code on the form and thought we’d come back to it and get it running quickly. Well, We’re back and it’s not!!!
We totally missunderstood how the call to the service worked and genuinely (though stupidly ) assumed we could call a browser page and have the data returned from the service call there as a demo.
The sample solution form and functions on it are all straight forward (that’s why we were sucked into thinking this was easy), but the code in the test page at http://localhost:8080/examples/restfulws_testpage.html is a bit boggling to say the least.
Are there any tutorials on how this works and what this web page is actually doing?
How can other applications make these calls (obviously we want to allow other apps to draw data from our app)?
Can these services ONLY be run from a specifically written web page??
We are a little lost with this entire concept - though it looked oh-so-easy at Servoy Camp!
It also contains a few url’s to external websites to provide you with more information on the concept of RESTful Webservices.
Paul
To be honest - there is a load of stuff in those resources Paul - more than I can digest in a sitting for sure and I was hoping that since you guys had done all the hard work and created the Rest_plugin there would be some simple and easily understood (by the ‘javascript ignorant’ like me) methods of deploying it. I hadn’t realised I need to become skilled in those arts too.
I thought perhaps a run down and description of exactly what the web page you supplied is doing, and also some basic info on how this might be implemented in other systems (and I’m still not sure about the questions I posted) too.
I’m sure there are a lot of Servoy developers who could have jumped straight into using this stuff, and got to grips with the calling technology, but unfortunately we don’t count in that number and we’re gona need a bit of support with it. I’m certain it wasn’t Servoy’s intention to put the plugin out there and hope everyone would dive into learning the Restful scheme and develop those web pages on the fly, so now you’ve already done the heavy lifting Paul - why not share some how-to’s to go along with the sample solution?
As always your expertise is much valued Paul, so feel free to shoot us down if we’re being particularly dumb. Many of our clients are calling for data sharing using web services and we really need to get to grips with it ASAP.
I think the “issue” here is more about “how do I use/consume the RESTfull Web Services I’m exposing (in Servoy) from an external application”.
(RESTful) webservices are (in general) not meant to be called by a user directly (from within a browser or whatever other tool, for that matter).
(RESTful) webservices are meant to be implemented by developers in their programming language of choice.
Setting up a RESTful webservice in Servoy is simple, as described in the docs, by creating one or more of the 4 methods and then you’re done.
How other applications then consume (call) these webservices, well, that is a completely different matter. Depends on the language they use etc. etc. So, that is not something to ask here.
I think it will pay off to read the docs and follow those links on RESTful webservices, because there you’ll find info on the concept of RESTful webservices (nothing native to Servoy).
I will take a note to add some info on how to use the test webpage we ship, but that is just a little testing page, nothing more.
Thanks Paul - I think we got the completely wrong impression when we saw the demo at Servoy Camp. What we came away with was the impression that we had the ability to create an http string and get our data out - and therefore usable in some other way - obviously very naive of us! Thanks for putting us right.
Looks like another area of Servoy that promised so much but is pretty useless to us without another extended skill set! Guess we’ll have to work on that one too and your extended notes on how the test page works will be very much appreciated.
What we came away with was the impression that we had the ability to create an http string and get our data out - and therefore usable in some other way
Well, that is exactly what it is and what it does! So, the impression we gave you is spot on!
The point is: You need to define the “in some other way” part of your quote above.
Which part of the sniplet below of the docs is not clear?
ws_read():Object to retrieve data
By performing an HTTP GET on the url /servoy-service/rest_ws/solutionName/formName, the ws_read() method will be invoked. Arguments can be specified in the url, like /servoy-service/rest_ws/solutionName/formName/value1/value2. The arguments will be applied to the invokation of ws_read().
The method must return a JavaScript object. The object will be serialized and placed in the body of the HTTP Response. If the return value of the method is null, a NOT_FOUND response (HTTP 404) will be generated
pbakker:
Which part of the sniplet below of the docs is not clear?
ws_read():Object to retrieve data
By performing an HTTP GET on the url /servoy-service/rest_ws/solutionName/formName
This bit. I have no clue from this how I get the HTTP request to use a GET (or anything else for that matter) I suspect your (now) promised info on the sample web page will clarify it
The additional info on the test page (it’s not a sample page!!) will not educate on the basics of HTTP Request which are the underlying technology used for RESTful web services (not specifically in Servoy, but everywhere).
The plugin in Servoy makes it very easy to expose RESTful webservices (just create a form with one or more of the 4 mentioned methods). How you call/consume those methods is outside the scope of Servoy.
How do you want to consume these webservice? From what application/platform?
FYI, if your interested, I do have a plugin that I haven’t released yet which runs as a servlet and exposes your methods to URL’s. Then the result of your method is return back to the browser in whatever format you want. It also provides an option to serialize a dataset to a JSON string for programatic access to your data. So, essentially you get something like: http:///servoy-service/iTechWebService////
That will then startup a headless client, and persist for the session (so you can set globals, etc). So each user gets their own headless client, unlike the webservice plugin which uses a pool of headless clients and can’t utilize session data, like globals.
Let me know if your interested in test it and I can get it cleaned up for a demo.
Note that one of the key constraints to the REST style is statelesness which is also an assumption applied in the rest_ws plugin.
For performance reasons a pool of headless clients is used, any of these HCs can be used by any client request, so when you use globals in the solution you will get unpredictable results.
pbakker:
How do you want to consume these webservice? From what application/platform?
Paul
Paul - I suspect our Clients will want to use the services in a number of applications, from SAP to in house apps.
What I was really hoping to do was to build a little demo for them where we would recover some sensible data from our system and give them some indication of how they might consume that data. I’m working at your test page for that purpose.
The part you quote is about a put operation, while you’re asking about a get operation…
Assuming you want to do the PUT here, the answer is in the quote you already included:
the post body is expected to be an object with firstName and/or lastName properties: {“firstName”:“Jane”}
That is how “Jane” is passed: in the body of the HTML Request.
The sample test page does all that for you already: just specify the URL, specify the body content (if needed) and press the appropriate button (put, get, post or delete).
For example, if I have the standard sample solution for restful webservices active in my Servoy Developer and I open the testpage (on http://localhost:portno), if I press the “send via Get” button, the server response will be a XML document with the ID’s of my employees.
If I add “/1” to the URL and press the same button, I get an XML with the ID, first and last name of the employee with ID 1.
I think you really need to read up on what restful webservice actually mean, because otherwise it’ll be difficult to get your head around it.
I get your point Paul but I’m attempting to use the PUT code to build a GET with multiple parameters. I’ve realised (bit late I know ) that the XML box is what sets the parameters, and I can convert that to my own tags for searching. Cant get my head around how the test page reads that XML yet - and I think that’s my stumble block.
Obviously I can rewrite the code for the form functions to return what we need - its just how the test page handles that - I assume any number of values in the return can be handled?
Arguments can be specified in the url, like /servoy-service/rest_ws/solutionName/formName/value1/value2
This quote comes from the desciption of “ws_read():Object to retrieve data”
For the ws_read() operation (and the ws_delete operation for that matter), you don’t specify params in the body of the HTTP Request, but in the URL. This is how RESTfull Web Services work.
We actually had some issue when getting this plugin to work properly (not to mention it lacks a lot of usually-very-basic features).
the plugin apparently does not work if ‘mustAuthenticate’ is active, we couldn’t turn off authentication so we had to create a new duplicated solution.
beyond that this plugin seems to work only with the first form in alphabetical order, calling any other’s method will return a 500.
What’s wrong with the JSON serializer/deserializer? Is it REALLY marshaling a JS array as a Java Array? Never mind, we created a port of the standart js implementation you can find at json.org.
So after two or three chubby workarounds we found a stopper. Not only authentication is not supported, it is even lame (impossible?) to implement. Unsolicited idea: providing a way to get the original java request,response objects would be a winner (I don’t want a wrapper, that would be too much).
Since one is forced to turn on ssl manually using low-level tomcat configurations, and since this plugin does not provide authentication we considered the idea to rewrite it using jruby.
That, beside jruby being an open source high experimental project, worked fine, with authentication and proper json.
Best Regards.
PS. We were totally waiting for such a feature as REST WS. Turned out to be a marketing-non-feature. That’s too bad.
Sorry to hear that the plugin did not live up to your expectations. Some feedback on the items you mention:
1- This is documented . BTw: you do not have to duplicate the solution you already have: just create a new solution, one that doesn’t have mustAuthenticate set to true and include in this new solution the one you already have.
2- Cannot reproduce this, so something else/specific must have been going on in your environment. If you have a reproducible case, please file a case for this
3- This is a bit odd indeed, will ask to see if this can be improved
5- Altering the plugin to return the raw, unwrapped request and the ability to return a HTTP Response is possible (the plugin is open source), but I do not expect to see that happening in this plugin.