Nathan,
From what I know of SPA you are correct that the server side technology can be anything I believe.
In that case either CGI, ASP.Net, COBOL, XMLSERVICE CGI or whatever would work.
@Kelly, not knowing the politics of your office environment, why not stir it up and become the guy that does both COBOL and .Net.
I did a user group presentation last night and we had this very discussion of us VS them. I always like to put myself on both sides and try to bring teams together, although it doesn't always work depending on corporate culture and the personalities in play.
If your management see's that you're flexible and also wanting to learn that adds value to your position in my eyes.
Regards,
Richard Schoen | Director of Document Management Technologies, HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx
www.rjssoftware.com
Visit me on: Twitter | LinkedIn
------------------------------
message: 2
date: Tue, 19 May 2015 14:13:27 -0600
from: Nathan Andelin <nandelin@xxxxxxxxx>
subject: Re: [WEB400] IBM i authentication and RESTful web service
design
On Tue, May 19, 2015 at 7:44 AM, Kelly Cookson <KCookson@xxxxxxxxxxxx>
wrote:
Why not just learn .NET web and mobile development and keep everybody on
the same standards?
Given your preference for single page applications (SPAs) and retaining
"state" on clients, it seem to me that the only reason for ASP.NET would be
when clients need to access resources on Microsoft servers.
Wouldn't ASP.Net be completely superfluous, for clients that need to access
IBM i resources? No need for ASP.Net to dynamically generate HTML because
HTML would be static. No need for ASP.Net to maintain sessions, because
clients maintain their own state. No need for ASP.Net to provide a gateway
to IBM i data and other resources because those resources could be accessed
via an IBM i HTTP server and an IBM i Web Services Utility.
In the case of IBM i resources, it appears to me that ASP.Net would just
add latency, add a potential failure point, add complexity, add needless
security requirements, be a potential bottleneck, add cost, and be
completely unnecessary. It could save time, save money, improve security,
and improve the user experience by eliminating ASP.Net from the mix.
This perspective assumes that you have real intent to develop SPAs which
maintain client state, and control the interactions between the client and
an IBM i HTTP server. The HTTP server and an IBM i Web Services Utility
could be the gateway to IBM i resources.
Although the client's interactions with a Web Services Utility might be via
simple URI and an exchange of JSON objects, you might streamline the
interface via a JavaScript API which might be paired with the functionality
of the Web Services Utility.
var tableName = 'STUDENTS';
statusObject = wsuStatusObject();
studentRecord = wsuGetRecordObject(tableName);
studentRecord.lastName = form[0].lastName.value;
studentRecord.firstName = form[0].firstName.value;
studentRecord.middleName = form[0].middleName.value;
studentRecord.gradeLevel = form[0].gradeLevel.value;
wsuWriteRecord(studentRecord, statusObject);
if (statusObject.error) {
...
}
midrange.com
