Re: IBM i authentication and RESTful web service design

@Nathan,

I really appreciate the questions you have raised. They are pushing me to learn. 

I don't have good answers for all of the issues you have raised. I would at least like to share my initial reactions.

 >> My preference tends to favor doing more on the server, 
>> but that would be a minor quibble.

It's not that I think SPAs are better than server side web applications. It's that our managers perceive no need, and have no desire from a maintenance perspective, to introduce server side web applications on the IBM i (e.g., coded in Java or PHP). Our shop currently does all web application development using .NET. SPAs with IWS REST services would simply be a strategy for developing web and mobile solutions without introducing any new code bases or server side web application on the IBM i. (Our .NET web and mobile developers already use HTML, CSS, JavaScript, AJAX, JSON and the Angular framework.)

>> Do you grant authorities to IBM i resources to specific
>> users, and user groups? Would it really be a good idea 
>> to run all your web services under 1 generic user profile?

IWS lets you set the user profile for a service. We could have a few user profiles for different categories of services. Since our development teams are organized by lines of business, each development team would be responsible for creating and maintaining the user profiles required for the services provided to their lines of business. Still, this is something to think about and plan in more detail before assuming we have a workable solution.

>> Do you have different database environments where each 
>> has a different library list? Would it really be a good 
>> idea to run all your web services under a single library 
>> list?

The IWS service runs a COBOL program. Couldn't the COBOL program call CL programs to modify the library list as needed? That is, couldn't the COBOL program call a CL program to add whatever libraries are needed in the library list, then run the business logic of the service, then call another CL program to remove the libraries from the library list? Maybe I'm missing something as an OPM COBOL developer who have never created an IWS service. If it does work, however, I think this would give our services relatively fine-grained control over library lists.

>> What do you do about data transfers that may exceed the 
>> number of rows in an array?

I have to admit not knowing the technologies well enough to give you a good answer. However, in general, we don't want to pass huge row sets (huge JSON files) back to the SPA on the client. The JSON being passed back is for display in the browser. We might certainly pass back a large enough JSON file that a user will have to scroll or to see all of the results, but we don't want the user scrolling hundreds of pages worth of records. Still, I'm keeping this issue in mind as I continue to explore. 

>> What sort of REST interface supports complex filter conditions
>> such as get me the list of students where district equals 'XXX'
>> and school equals 'XXX' and fiscal year equals 2015 and grading
>> term equals 4 and last name begins with 'A' and first name 
>> begins with 'A' and grade level equals 7?

I again have to admit not knowing the technologies well enough to give you an answer. I would be surprised if REST had become so popular if it did not allow for filtering. A quick Google search turned up some articles about filtering and REST (e.g., http://stackoverflow.com/questions/1296421/rest-complex-applications/1297275#1297275, http://docs.telerik.com/platform/backend-services/development/rest-api/querying/filtering) as well as a RESTful Best Practices handbook that talks about filtering (http://www.restapitutorial.com/media/RESTful_Best_Practices-v1_1.pdf). Of course, being able to find a few online resources is not the same as having a working solution. This too is something I will keep in mind as I continue to explore.

>> Rather than downloading a list of all students via getAll(), 
>> consider offering VCR controls to navigate from page to page. 
>> How would IWS handle that?

Would we be navigating from page to page in a single page app (SPA)? Might we be able to use client-side caching and views in the MV* architecture of the SPA to come up with a functionally comparable solution? I really don't know. I don't know the capabilities of a well-designed SPA using a framework like Angular.  

>> Modernization is more about offering better, more functional
>> user interfaces, as opposed to removing functionality the 
>> users may take for granted.

I couldn't agree with you more. However, the vast majority of our user interfaces to the IBM i are 5250 green screens. I don't see how SPAs that use REST services via IWS will make our user interfaces less rich or less functional than 5250 green screens. 

The IBM Redbook "Modernizing IBM i Applications from the Database up to the User Interface and Everything in Between" contains sections about using IWS. The Redbook only talks about IWS in the context of web services, and does not specify the type of consumer. I suppose one could assume a "consumer" in the Redbook refers to applications other than UIs. Yet, if I'm understanding the architecture correctly, there's no reason why a consumer could not also be an SPA running on a client browser.

Again, thanks for helping me explore our options.

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Monday, May 18, 2015 3:09 PM
To: Web Enabling the IBM i (AS/400 and iSeries)
Subject: Re: [WEB400] IBM i authentication and RESTful web service design

@Richard,

Roy Fielding expressed a great deal of frustration with people hijacking his acronym (REST) to describe their various web services APIs and protocols. He suggested that people come up with their own acronyms.
Otherwise, why go to the bother of categorizing and articulating 6 key architectural constraints in a thesis?

Roy made a point, saying that PROCESSES come and go, but DATA remains, and REST is about accessing DATA; A little pedantic, perhaps. But he created the SPEC.

@Kelly,

I believe I understand your point about creating single page applications, having a desktop look and feel, maintaining state in the browser; Server components tend to be more thin and light-weight, while the client tends to be more "thick".

My preference tends to favor doing more on the server, but that would be a minor quibble. Your preference for doing more on the client may be an okay architectural choice; the devil is in the details. Just don't make so many constraints on the server, that users suffer from lack of functionality, COBOL developers suffer from tedious configurations, or the IWS becomes a bottleneck.

Part 3 of the IWS article series references a well-defined "studentRec", and provides procedures to create(), update(), remove(), getByID(), and getAll(). In addition to my earlier questions, you might consider offering various filter and order-by options in the getAll() procedure. Rather than downloading a list of all students via getAll(), consider offering VCR controls to navigate from page to page. How would IWS handle that?

Modernization is more about offering better, more functional user interfaces, as opposed to removing functionality they users may take for granted.
--
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.