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