Re: 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.