Question Webspeed As A Api Component

rumi

Member
Hi friends,
i would like to write a simple web application (in expressjs) and use webspeed as a api to pull data from Progress database. Do you have someone experience with this?

For expample on url:

/WebspeedApi/customers - to get all customers
/WebspeedApi/customers/1 - to get customer with id 1
/WebspeedApi/products - to get all products
.
.
.
And of course how to setup some access restriction ....

Thanks

Rumi
 

Cecil

19+ years progress programming and still learning.
Are you using Apache?
What format would you like to be returned HTML/XML/JSON?
 

zerovian

New Member
I gave a talk on how to do this at PUG Challenge back in June.

You can d/l the powerpoint and samples here:

Look for "REST for any application".
 

joey.jeremiah

ProgressTalk Moderator
Staff member
i would highly recommend using webspeed instead of the rest adapter. we started using the rest adapter because that is the recommend approach but eventually scrapped it and used webspeed.

a few major advantages to using webspeed over the rest adapter come to mind -

1. webspeed is far easier to install, setup and maintain than the rest adapter's whole java server, webapps mess. especially if you need to install the servlet engine (for example on unix/linux), setup the authorizations and tie it to progress. not to mention java compatibility and many other problems. in comparison, webspeed is a regular progress installation and configuration (that you would have to do anyway for the rest adapter's appserver).

2. you don't have that cross origin resource sharing (cors) headache with webspeed because the messenger is on the same web server host and port which will require alot of research in java and java servlets to setup. you won't find anything in the progress docs about it. even progress tech support had no clue. cors is also slower or less efficient because it requires the browser to send an additional http option request for practically every request it makes.

3. webspeed allows you to send back any data not just json, like, pdf's, word and excel files.

4. we started using the rest adapter in 11.3 which wouldn't allow you to get the client ip address (maybe this feature was later added) which we needed for our security. of course, you can get the client ip address in webspeed.

5. the rest adapter's drag and drop designer is really redundant since we have a single gateway (and i would think most frameworks would also) for all our services instead of creating and maintaining hundreds of api's.

i don't see any point in using the rest adapter.
 
Last edited:

zerovian

New Member
WebSpeed works ok with REST for some stuff, but unfortunately, if you want access to all the REST verbs, you'll have to use something else. WebSpeed messenger only supports GET and POST. PUT and DELETE are filtered out.

Although in 11.6, PASOE webspeed transport is a lot more like current WebSpeed and you can build your own REST framework that is much simpler than REST adapter. You also have full access to all the classic webspeed environment such as remote host address, server name and similar. Its also much easier to deploy than classic rest since it includes the webserver.
 

joey.jeremiah

ProgressTalk Moderator
Staff member
cool! i'll look at the new webspeed when we upgrade.

btw i wanted to ask, if i'm not mistaken pasoe apserver/webspeed agents run on separate threads instead of separate processes?

if the progress programs running on these agents make calls to c/c++ libraries then those libraries have to be thread safe?
 

zerovian

New Member
Yes; code runs in separate threads within a single agent executable process; although you can start multiple agents if you want. There's a couple of configuration options for how third party libraries are accessed. You can force access to all be serialized, but if you know its thread safe, you can mark it as such, and calls to methods in that library can be concurrent.
 

RealHeavyDude

Well-Known Member
There is another thing why I did not use the REST adapter yet: Security.

I am on OE11.3.1.

Our internal single sign-on solution is based on an infrastructure ( based on smartcards holding an SSL client certificate and a location aware authentication ) that ultimately provides the users' identity and location on the HTTP headers of the request - either as an ASN.1 token or plain HTTP headers. On WebSpeed or an intermediatey Java Servlet you can easily grab those HTTP headers and process them or pass them as additional parameters to the ABL procedure running on the AppServer, respectively. With the AppServer adapters you can't get this information into the ABL procedure that needs to perform location aware access control - unless you hack the adapters and add the missing pieces yourself. At least I did not find a feasibly solution.

Heavy Regards, RealHeavyDude.
 
Top