Re: IBM i authentication and RESTful web service design

Kelly

You have overseen your maybe biggest problem of all and that is that COBOL
isn’t very well supported in ILE web-development on IBM I since most ILE
frameworks and tools are done in RPGLE/C and most others in PASE (Java,
PHP, Ruby etc.) using XMLSERVICE (
http://yips.idevcloud.com/wiki/index.php/XMLService/XMLService ) to
communicate with the ILE environment. You may be better off in the latter
(PASE/XMLSERVICE).

On Tue, May 19, 2015 at 2:18 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:

> @Nathan,
>
> >> Regarding library list munging at runtime, are you suggesting
> >> that the IWS pass the necessary parameters to each and every
> >> procedure in order for them to do that at runtime? Aside from
> >> complicating the procedure interface, wouldn't users be affected
> >> by the performance implications?
>
> >> Regarding constraints on the size of data sets which may be
> >> transferred from a server to a client, I view that as an application
> >> decision, which should not be an constrained by the communication
> >> interface.
>
> >> When the list of students is ordered by grade-level and student
> >> name, bound to a back-end SQL result set, one would need to
> >> retain the state of the SQL result set on the server in order to
> >> support such navigation on the client.
>
> I am at the end of my (newbie) knowledge in terms of being able to respond
> to these issues. I just don't know enough about SPA development patterns to
> know what might, or might not, be good ways of dealing with these issues. I
> will definitely keep these issues in mind as I learn more about the nuts
> and bolts of SPAs and the services they consume.
>
> >> Regarding the user profiles which IWS servers run under, the real
> >> question is should every individual user be able to adopt the authority
> >> of the IWS user profile?
>
> The user profile for the IWS service does not have to be the same user
> profile that runs the COBOL program. We never have to use the IWS default
> user profile if we don't want to do so. We have some amount of flexibility
> in terms of configuring user profiles. However, until I actually create a
> few IWS services, I won't know how we want to handle the security and
> authority issue you bring up. I might seek some guidance about this from
> IBM. I would hope the architects and developers of IWS have thought about
> this at some point since releasing IWS back in V5R4.
>
> >> So the "answers" you find on the internet, relevant to REST
> >> may or may not work for IWS configurations.
>
> Point taken. Like you've said, the devil is in the details.
>
> It's possible that SPAs with REST services via IWS won't work for us. We
> might end up back on a CGI approach. But SPAs with IWS is too enticing to
> not explore.
>
> Thanks,
> Kelly
>
>
> -----Original Message-----
> From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan
> Andelin
> Sent: Monday, May 18, 2015 6:40 PM
> To: Web Enabling the IBM i (AS/400 and iSeries)
> Subject: Re: [WEB400] IBM i authentication and RESTful web service design
>
> Kelly,
>
> I'm glad my questions are provoking thought and research. Just to clarify,
> my questions are relative to the IWS, not REST interfaces in general. It
> appears to me that the IWS has some configuration requirements
> (constraints) for mapping browser inputs to procedure inputs, and mapping
> procedure outputs to JSON and XML.
>
> So the "answers" you find on the internet, relevant to REST may or may not
> work for IWS configurations.
>
> I agree that an SPA may be a REST client; JavaScript provides that
> capability.
>
> Regarding library list munging at runtime, are you suggesting that the IWS
> pass the necessary parameters to each and every procedure in order for them
> to do that at runtime? Aside from complicating the procedure interface,
> wouldn't users be affected by the performance implications?
>
> Regarding constraints on the size of data sets which may be transferred
> from a server to a client, I view that as an application decision, which
> should not be an constrained by the communication interface.
>
> Regarding the user profiles which IWS servers run under, the real question
> is should every individual user be able to adopt the authority of the IWS
> user profile?
>
> In regards to page by page navigation, I meant navigating lists of
> records, not leaving one SPA and navigating to another, though the
> interface should support that too.
>
> When the list of students is ordered by grade-level and student name,
> bound to a back-end SQL result set, one would need to retain the state of
> the SQL result set on the server in order to support such navigation on the
> client.
>
> I understand that your shop may not want to maintain server code that
> generates HTML from COBOL; you may only want to generate JSON for client
> consumption, and possibly have servers consume JSON sent from clients. If
> that's your choice of architecture, so be it.
>
> Again, it's not REST that might constrain your user interfaces, but rather
> the IWS procedure interfaces.
> --
> This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
> list To post a message email: WEB400@xxxxxxxxxxxx To subscribe,
> unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives at
> http://archive.midrange.com/web400.
>
> --
> This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
> list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/web400.
>
>