Re: IBM i authentication and RESTful web service design

@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.