How to POST binary data (application/octet-stream) to a PASO

Posted by slacroixak on 19-Sep-2019 17:23

OE 11.7.5  Trying to achieve a sample REST WebService to upload binary data from an ABL http client Request.

On the client side, I prepare a POST request this way:

DEFINE VARIABLE oRequest   AS IHttpRequest  NO-UNDO.
DEFINE VARIABLE oResponse  AS IHttpResponse NO-UNDO.
DEFINE VARIABLE filemptr   AS MEMPTR        NO-UNDO.
DEFINE VARIABLE oBody      AS OpenEdge.Core.Memptr NO-UNDO.

COPY-LOB FROM FILE ".\TestPostPictures.zip"  TO filemptr NO-CONVERT.
oBody = NEW OpenEdge.Core.Memptr(filemptr).
oRequest = RequestBuilder:Post( 'localhost:8810/.../PostBinSmallFile' , oBody):Request.
oRequest:ContentType = "application/octet-stream".    
oRequest:ContentLength = GET-SIZE(filemptr).
oResponse = ClientBuilder:Build():Client:Execute(oRequest).

On the AppServer side, I expose a simple REST service with resource POST associated to a class VOID method with one input MEMPTR parameter. 
Simple Input Mapping  from  HttpMessage:Body   to   prmptr  (java:byte[] )

    @openapi.openedge.export(type="REST", useReturnValue="false", writeDataSetBeforeImage="false").
    METHOD PUBLIC VOID PostBinSmallFile (pmptr AS MEMPTR):
        COPY-LOB FROM pmptr TO FILE "./received.zip" NO-CONVERT.
        
        FINALLY:
            SET-SIZE(pmptr) = 0.
        END FINALLY.
    END METHOD.    
This always results in HTTP Error 415 Unsupported Media Type   The AppServer access log says:

"POST /AKQRest/rest/AKQRestService/PostBinSmallFile HTTP/1.1" 415

A few articles advise to convert the binary content to text with BASE64-ENCODING, but I really would like to avoid that for performance sake (that service will be used intensively).

I've tried the application/zip content type with the same result.  The http client is happy to send, but I have not yet found how to define, bind and code the server side.

Any hint of piece of doc I may find for that?

So far, I know how to GET or PUT json stuff for simple parameters or temp-tables.  I am missing how to handle binary data.

Posted by Jean-Christophe Cardot on 20-Sep-2019 05:57

Hi Sébastien

OE REST Webservices can only do json :(

If you hack a little, you might do anything not binary.

But for binary you will have to go web handlers.

I'm using URL Rewrite so that my web handkers URIs are consistent with the REST ones.

Regards

JC

Posted by bronco on 20-Sep-2019 06:19

JC is right, application/json only for the REST  adapter. Now of course you can base64 encode the data since you seem to control both ends.

Now, since in modern days example code turns into production code amazingly quickly, you might want to go for the WebHandlers straight away.

All the definitions of REST are stored in the .services folder in PDSOE and they a genuine nightmare, not to mention all sorts of limitations with the REST adapter.

Posted by Jean-Christophe Cardot on 20-Sep-2019 16:30

had I known the limitations of the REST adapter, I would have done everything using web handlers...

All Replies

Posted by Jean-Christophe Cardot on 20-Sep-2019 05:56

Hi Sébastien

OE REST Webservices can only do json :(

If you hack a little, you might do anything not binary.

But for binary you will have to go web handlers.

I'm using URL Rewrite so that my web handkers URIs are consistent with the REST ones.

Regards

JC

Posted by Jean-Christophe Cardot on 20-Sep-2019 05:57

Hi Sébastien

OE REST Webservices can only do json :(

If you hack a little, you might do anything not binary.

But for binary you will have to go web handlers.

I'm using URL Rewrite so that my web handkers URIs are consistent with the REST ones.

Regards

JC

Posted by bronco on 20-Sep-2019 06:19

JC is right, application/json only for the REST  adapter. Now of course you can base64 encode the data since you seem to control both ends.

Now, since in modern days example code turns into production code amazingly quickly, you might want to go for the WebHandlers straight away.

All the definitions of REST are stored in the .services folder in PDSOE and they a genuine nightmare, not to mention all sorts of limitations with the REST adapter.

Posted by slacroixak on 20-Sep-2019 12:10

Thank you Bronco and Jean-Christophe,

I had also heard about the WebHandlers but started to play with the nice little REST wizards at first.  I can imagine many other benefits of doing all with the WebHandlers technique.  I suppose it might be easier to deploy.

Posted by Jean-Christophe Cardot on 20-Sep-2019 16:30

had I known the limitations of the REST adapter, I would have done everything using web handlers...

Posted by goo on 20-Sep-2019 17:16

Is it that much work to transfer from previous REST interface, to use web Handler?

Sendt fra min iPad

20. sep. 2019 kl. 18:32 skrev Jean-Christophe Cardot <bounce-jeanchristophe@community.progress.com>:

Update from Progress Community
Jean-Christophe Cardot

had I known the limitations of the REST adapter, I would have done everything using web handlers...

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

Posted by Jean-Christophe Cardot on 23-Sep-2019 08:25

>  Is it that much work to transfer from previous REST interface, to use web Handler?

May be not so much, but once you have developped a lot of REST adapter web services already, it is some work to be done, with possible regressions and necessary testing, and no budget for that ;)

Posted by Peter Judge on 23-Sep-2019 19:06

The PAAR file is a zip file that contains the service mapping and routing in  XML and embedded-in-CDATA-XML. It's not fun to work with (or even read).
 
I mentioned the DataObjectHandler in another thread. That's an ABL webhandler that replaces the PAAR (and its contents) with a single JSON file per service. It should be possible to read the XML and produce JSON. Once that's done, you should only need to add a handler definiton into openedge.properties and you should be good to go.
 
 
 
 

This thread is closed