Report Output

prattspets

I'm very new to RESTful API concepts, so I just want some feedback/tips on creating my first service. I have created a service using the example services provided as a guide (i.e HTTP_USERS_SERVICES and HTTP_CONTACTS_SERVICES). GET-ting data from a table is coming along smoothly, but where I'm a little stumped is how to handle dynamic content that takes some time to process. For example, if I want to have a report generated that will take some processing time and then send that back in the body to the client, I'm concerned that I will run into "Error 500 - Internal Service Error" because the web server will time out for some of the slower reports.

One thought I had on how to handle this is to have a service that the front end can request the output of an empty record repeatedly. Once the report is done processing, it can be written to the empty record, and the next GET request from the front end client will get the report output, instead of the empty record (null).

I'm sure there may be better and more standard ways to handle this, so please let me know what you think.

DonBakke

I am not evading your direct question and I will circle back to it eventually, but I must ask why your report request might take a long time to process. Ideally, no REST (or HTTP) request should take long to process.

What kind of report are you creating? That is, are you returning JSON, HTML, PDF, etc.? Is the report user-driven (i.e., you are allowing the user to define the criteria) or do you control this? What is your worst case scenario?

prattspets

The reports are user-driven. It would require some input from a user (i.e. date range, etc. ) and then generate a report according to that input. Report response would be in JSON. Worst case processing time would be a few minutes.

DonBakke

Worst case processing time would be a few minutes.

What would cause the report to take a few minutes? Is it the time needed to select the data or the time needed to prepare the results?

prattspets

Processing time is for running a RLIST statement in OI based on the input from the user.

DonBakke

So you are allowing any RLIST statement to be submitted or will you control this via a UI? I'm gathering the former based on your expectation that some long delays can occur. My strong encouragement is to design around such potential bottlenecks. Not to sound too pedantic, but web apps are not intended to have the same flexibility and features as desktop apps due to the differences in architecture and user expectations (i.e., speed of performance is more critical than in a desktop environment).

If you simply cannot exercise that level of control, you probably want to run a few worst case scenario tests to see if this is really a potential problem. If it is, then there a few of approaches you can take. What is the UI/client that will be used to call your web service?

prattspets

The UI will be a web app using java. It don't have any specifics on it yet, because it is just a concept thus far. I am just trying to think it through to find out what I would want to plan for handling long requests that potentially could time out. I am planning on having reports that are available through the REST API to be optimized in such a way that they will respond quick enough to avoid those issues.

DonBakke

My suggestion is to wait and see if you need to do anything. I really doubt this will become a timeout problem. We have a web and mobile app that calls the same REST API and due to the nature of the project the request can take several minutes to process. I've never seen it timeout. I believe that your client-side HTTP request can request an extended timeout session with the server. That is outside of my personal knowledge, but I seem to recall our JavaScript programmer doing something similar. Thus, it isn't anything you need to do in the web API.

prattspets

Thanks Don