Hi,
We are planning to create products based on OpenEdge appservers in the cloud, that are being accessed from REST clients (like Telerik and JSDO GUIs) and from other cloudservices.
So that involves .p and .cls running in OpenEdge Appserver processes, with REST adapters in front of that. We are already experienced in writing Appserver code, but we don't feel very confident with the OpenEdge REST wizardry.
Now it finally dawns on me that one can achieve the same with Webspeed instead Appserver. Webspeed can execute the same .p and .cls code so we can just reuse most of our logic, is that true? Is is also true that one can simply implement REST services in Webspeed without using the REST adapter and its wizards?
So I am wondering, would Webspeed be a better choice, or are there certain drawbacks with Webspeed so it is better to stick with the plan to use Appserver?
Thanks,
Jurjen.
Hi Jurjen,
All great questions. You can use WebSpeed to do handle some REST requests but it does not handle all of the verbs. People have worked around this and are using WebSpeed as their app server.
Now WebSpeed gets a complete OO makeover with all verb support in PASOE for 11.6. At that time what you want to do will be even easier. You would need to write your own web handler for dispatching to the proper .p/.cls
Thanks
Shelley
Hi Jurjen,
the alternative is to keep using the REST Adapter (at least until 11.6 is available) and build a few flexible REST interfacess. We don't use a OE Mobile Project, and we don't expose the "Business Entity" classes from OE mobile. We don't have to go through any PDSOE tooling at all to expose a new Business Entity.
But our REST endpoints work well with JSDO and Kendo UI:
confluence.consultingwerkcloud.com/.../Generic Service Interface for JSDO with Kendo UI dialect
On the AppServer we have basically two classes that serve as the Service Interface and dispatch calls to the actual Service objects (typically Business Entities).
Regards,
Mike
Hi Jurjen,
the alternative is to keep using the REST Adapter (at least until 11.6 is available) and build a few flexible REST interfacess. We don't use a OE Mobile Project, and we don't expose the "Business Entity" classes from OE mobile. We don't have to go through any PDSOE tooling at all to expose a new Business Entity.
But our REST endpoints work well with JSDO and Kendo UI:
confluence.consultingwerkcloud.com/.../Generic Service Interface for JSDO with Kendo UI dialect
On the AppServer we have basically two classes that serve as the Service Interface and dispatch calls to the actual Service objects (typically Business Entities).
Regards,
Mike
Hi Mike,
What a beautiful Confluence page, I love it!
We already arrived at the same conclusion that routing and parsing in ABL (and dynamic JSDO catalog generation) is easier than using the tooling for every BE.
Just wondering how Webspeed compares to Appserver for this purpose.
Hi Jurjen, as of today, WebSpeed can only handle GET and POST requests. The JSDO requires also PUT and DELETE.
So for Catalog Generation and read Access, WebSpeed is a good alternative - until those future enhancements to WebSpeed that Shelley mentioned become available and WebSpeed can handle the full Story..
Hi Jurjen, as of today, WebSpeed can only handle GET and POST requests. The JSDO requires also PUT and DELETE.
So for Catalog Generation and read Access, WebSpeed is a good alternative - until those future enhancements to WebSpeed that Shelley mentioned become available and WebSpeed can handle the full Story..
or if you want straight REST you could draw some inspiration from the presentation on the PUG Challenge last year (you were on the front row taking selfies with *my* camera :-) ). With "some" code in between the classes (.p) which are used as entry point for mapping the URL's you can limit the actual amount to 5 or 6.
community.progress.com/.../bronco_5F00_oostermeyer_5F00_REST-assured.pptx
The backend I used is iMo so that's familiar.
Hi Jurjen,
you might want to look at our akera.io lightweight server built on node.js - http://akera.io
Full API for node.js is almost complete, if you want to give it a try let's have a beer in Copenhagen ;)
Agreed, waiting for 11.6 makes sense, to have the other verbs plus the Tomcat environment
Marian, beers in Copenhagen it is!
Cool, maybe we can bribe some Belgian friend to bring some real beer over :)
Belgian beer in Carlsbergtown. While we are there I would like to make some selfies. Bronco, can you bring your camera?
for you, no problem (you know how to operate my camera) :-)
We're using a WebSpeed-based webservice API which supports GET/POST/PUT/DELETE, we also use the HTTP Status Codes to return errors. But then we're running old tech (10.2B)
Matt.