REST and WEB Transport

[Team Research]

HI Team,

During webservice migration, we came to know that there is two different transport available in PASOE such as REST and WEB. This both transport services is using to create the REST API. Can any one please let us know, what is the key difference between REST and WEB transport?. Which is the best option to create the REST URL.?
In terms of architecture perspectives, What basis we should select the REST or WEB transport during the REST API development?

Your valueable response much appreciated.

 

[Jean-Christophe Cardot]

Hi anonymous forum member

REST transport is much more limited than WEB; you can only have text/json in the body of the web messages.
It may be simpler to implement because it is less low level than WEB; but you can create your own REST web handler once and reuse it for all of your endpoints.
Using WEB, the same API can do text/json but also return of load whatever kind of binary files you may need (pictures, worksheet files like Excel or Libreoffice, etc .).
I'm using both in the REST API I developped because I did not receive this advice when starting and lacked budget to rewrite everything to WEB, so the simpler json web services are REST while the "binary" ones are WEB.
(and I use URL rewrite in order for the caller not to see a difference in the URLs, so that my REST API stays consistent desìte using the 2 transports.)

TL,DR: if you have not started yet, use WEB.

YMMV though, I'm interested in knowing what the opther forum members think about this.

++

JC

 

[peterjudge]

Hi anonymous forum member

REST transport is much more limited than WEB; you can only have text/json in the body of the web messages.
It may be simpler to implement because it is less low level than WEB; but you can create your own REST web handler once and reuse it for all of your endpoints.
Using WEB, the same API can do text/json but also return of load whatever kind of binary files you may need (pictures, worksheet files like Excel or Libreoffice, etc .).
I'm using both in the REST API I developped because I did not receive this advice when starting and lacked budget to rewrite everything to WEB, so the simpler json web services are REST while the "binary" ones are WEB.
(and I use URL rewrite in order for the caller not to see a difference in the URLs, so that my REST API stays consistent desìte using the 2 transports.)

TL,DR: if you have not started yet, use WEB.

YMMV though, I'm interested in knowing what the opther forum members think about this.

++

JC

I agree on using the WEB transport over REST.

1. It's all in ABL, so debugging becomes simpler (for us ABL developers)
2. You can return any MIME type - not just the binary that @Jean-Christophe Cardot mentions, but also things like multipart messages or custom/vendor content types
3. You get far more control over how to deal with errors (both status codes and response data)
4. It is generally simpler to configure: using handler* properties in conf/openedge.properties or a .handlers file . The .PAAR format used for REST services cannot be simply generated (you must have a PDSOE project lying around)
5. Using the path parameters you can send groups of requests to a single webhandler. I don't think that's possible for the REST mapping tool (but may be wrong)

 

[Stefan]

We have exactly one web handler, listening on /web/rest, that handles the REST API for all our entities including documentation.

https://partners.exactfinancials.nl:8443/web/rest

 

[peterjudge]

We have exactly one web handler, listening on /web/rest, that handles the REST API for all our entities including documentation.

https://partners.exactfinancials.nl:8443/web/rest

One webhandler to rule them all, and in PAS to bind them?