I am converting a standard 3270 BMS application to PHP as a demonstration. My goal is to build a REST based application. My question concerns pagination when the response to a GET LIST collection is very large. I get the impression that putting a query string in the URL violates the spirit of REST but I can see a case where a query string that limits the list collection creates a type of page resource.
The reason I ask is that if I can refine the process, we have several similarly structured COBOL applications so I need a best practice. Right now my problem is that the 3270 application displays 20 items, retains the next record key in the commarea and waits for user to hit PF8 to page forward. The file being displayed is too large for a GET LIST collection, so how do you recommend using CICS REST support in CA1S or CA8K (this is a TS 3.2 region) to support a PARTIAL GET? Can I build a 206 STATUS with a Content-Range header? I noticed that in the LIBRARY AJAX example limits the number of books which seems to a bit of an easy way out. I realize this may not be a CA1S specific question but I think it has relevance since a large percentage of CICS COBOL programs have the 3270 display logic embedded in the same program as the actual business and data logic. Do I need to rethink my aspirations of developing a boilerplate REST application for VSAM based COBOL applications? To further complicate the issue, I have been experimenting with dojo.data JsonRestStore? I haven't made it far enough it actually try a test but it looks interesting. If you have experience, is it an answer for pagination?
In my opinion it is fine to use a query string to limit the number of entries returned in a REST GET LIST request. In IBM WebSphere sMash ZRM support, query strings are used to filter the entries returned on a REST GET LIST request, and also to determine the format of the response (e.g. ATOM vs JSON). We also developed a sample application for CA1S which used query strings to limit the number of entries returned on a list request.
So for example you could have "startat" and "maxcount" query string values in order to simulate the behaviour of the 3270 interface. It seems to be useful to remember that REST is intended to be a lightweight, easy-to-use form of Web Service which is highly productive and emphasises time-to-value over semantic purity.
Thanks for your response. I agree that it should be a fast and painless way to develop, just wanted to use best practice on the first one in order to set a good example.
To which sample ZRM application are you referring? I would like to try it and see how it compares to what I've been doing.
Thanks again.
Tags
Use the search field to
find all types of content in My developerWorks with that tag.
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular type of content or application that you're viewing.
My tags shows your tags for this particular type of content or application that
you're viewing.
