Re: IBM i authentication and RESTful web service design

Hi Nathan and Brad,

I obviously have a lot to learn. But please let me explain my thinking (right or wrong) so I can learn where I'm mistaken. 

Yes, I want to create web applications. But I want to compose these web applications by having browser interfaces communicate with web services. For example, suppose I need to develop web pages that allow employees to view their paystub information and to change their contact information. I would like to compose the web application from the following components:

1. a browser interface (a set of web pages) developed with HTML, CSS, and Javascript that sends HTTP requests to specific URLs and process the responses
2. a web service for the resource "employee contact information" at a specific URL that receives HTTP requests from the client and returns responses
3. a web service for the resource "employee paystub information" at a different URL that receives HTTP requests from the client and returns responses

I would develop the web services using CGI COBOL programming on the IBM i. By composing the web application in this way, we can re-use the web services in a hybrid mobile app, and our ASP.NET web and mobile developers can re-use the web services. If, for some reason, we want to migrate one of the web services from CGI COBOL to ASP.NET, we could migrate it without having to migrate the other web service. If we wanted to migrate both web services from CGI COBOL to ASP.NET, we could migrate them one at a time, resulting in two smaller projects that are easier to schedule and budget. 

Nathan, I respectfully disagree that Fielding's discussion of REST in his dissertation is geared toward non-browser clients. For example, when he lists the REST data elements in table 5-1 of his dissertation (p. 88), he says a resource identifier can be a URL and a representation can be an HTML document or a JPEG image. These are very compatible with browsers. HTML seems particularly aimed at browsers. When he lists REST connectors in table 5-2 (p. 93), he lists "browser cache" as an example of a cache connector. When he lists REST components in table 5-3 (p. 96) he lists Netscape Navigator as an example of a user agent. Moreover, Fielding specifically refers to "browser applications" when he discusses REST Architectural Views (see page 102 in his dissertation) and when he discusses how cookies and frames don't conform to REST constraints (see pages 130 and 142 in his dissertation). Fielding is a human being like the rest of us and might be wrong about some things in his dissertation. But I think he intend to include browser interfaces as clients when he talked about REST in his dissertation. I am open to being persuaded to a different conclusion about this. 

Brad, I think REST might come into play when one composes a web application where a browser interface communicates with a web service. REST is a set of software architectural constraints. Each constraint has its own benefits and its own downsides. I don't see how the benefits or the downsides of these constraints change based on the inner workings of a client. The HTTP requests are the same, and the HTTP responses are the same, whether the client is a browser interface or a Visual Basic .NET program or an RPG program using an HTTP API. The client is basically a black box as far as the REST architectural constraints are concerned. So, *assuming* one wants to get the benefits of REST architectural constraints, one could apply the REST architectural constraints when designing how the browser interface communicates with the web service. REST architectural constraints would be part of the internal architecture of the composed web application. Again, I am open to being persuaded to a different conclusion about this.

Thanks,
Kelly


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

Kelly,

Regarding additional resources, I have begun documenting our web portal. It is far from complete. Most of the hyperlinks are just placeholders for future use. The URL is a temporary address. But the "Introduction" section has content which is geared toward developers. Feel free to peruse.

http://www.radile.com:9220/rdweb/info/home.html?page=ptl/intro/intro.html&toc=ptl/toc.html

Based on previous conversations, some may be confused by your use of the term "web services". My understanding is that you're interested in developing "web applications", having browser user interfaces.

As "web applications" grow in complexity, how and where you manage state, and particularly whether you manage state on the client or the server is an important architectural consideration.

For complex applications which support browser user interfaces, it is better to manage state on the server, in my opinion.

The Fielding dissertation on REST, is geared toward simple (basic) services for non-browser clients.
--
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.