Idea Delivered

A RESTful Web Services API was added to the product with XPP 9.3.

It is available, and is distributed for use with any new installation or upgrade as of the XPP 9.3 release.

XPP Restful API Web Services

Replace Web Services with a RESTful API that is URL addressable for XPP functionality.

Low-level "micro" services (toxsf, compose, print, citi, etc) supported by XPP, that can be built upon for more high level customized  functionality.

Steve Piercey
Parents

  • Still working out some of the details, but I will try to answer some of your questions.

    The suggestion about 'wait' for the long API calls is valid. This would be 'print', compose, and user command , but I will point out that it is inconsistent as far as the API is concerned. All calls are synchronous except...

    Files will be sent/received as attachments. This is the only known way of delivering files that can be "streamed" and not eat up memory when the files get large. Any kind of HTTP client can deal with form-attachments and the file auto-magically gets placed onto the file system. It does also support "inline", so if you were in a browser application make XPP REST calls (via jquery or some other client), the file would be streamed directly to the web-browser.

    To get the status, you do a http://...../processes/:taskid. It returns the output of the command or a "running" if it is still active. Good idea about the current output being the last line of "stdout". Could be useful and sort of mimic what happens in the background processor. Will have to think about that.

    Files created by "print"; ie. psfmtdrv or divpdf will reside on the file system. You name it with arguments to the "print" and it must be retrieved with a 'getfile' after the task is completed. You dont want to be passing files as base64 encodings in JSON returns because of memory usage (as stated above).

    All good questions, and glad there is interest. REST is much better than SOAP

Comment

  • Still working out some of the details, but I will try to answer some of your questions.

    The suggestion about 'wait' for the long API calls is valid. This would be 'print', compose, and user command , but I will point out that it is inconsistent as far as the API is concerned. All calls are synchronous except...

    Files will be sent/received as attachments. This is the only known way of delivering files that can be "streamed" and not eat up memory when the files get large. Any kind of HTTP client can deal with form-attachments and the file auto-magically gets placed onto the file system. It does also support "inline", so if you were in a browser application make XPP REST calls (via jquery or some other client), the file would be streamed directly to the web-browser.

    To get the status, you do a http://...../processes/:taskid. It returns the output of the command or a "running" if it is still active. Good idea about the current output being the last line of "stdout". Could be useful and sort of mimic what happens in the background processor. Will have to think about that.

    Files created by "print"; ie. psfmtdrv or divpdf will reside on the file system. You name it with arguments to the "print" and it must be retrieved with a 'getfile' after the task is completed. You dont want to be passing files as base64 encodings in JSON returns because of memory usage (as stated above).

    All good questions, and glad there is interest. REST is much better than SOAP

Children
No Data