Hi Nathan, 

Don't feel badly. You pushed me to learn more about the terms and concepts of web services. I found an interesting Web Services Glossary published by a W3C working group (http://www.w3.org/TR/ws-gloss/). Here is what it says about web services:

"There are many things that might be called 'Web services' in the world at large. However, for the purpose of this Working Group and this architecture, and without prejudice toward other definitions, we will use the following definition: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."

I believe this is the way you are using the term web services. This is also why my use of the term was confusing.

To help myself think about the definitions in the glossary, I decided to use terms from the glossary (as best I understand them) to explain what I'm trying to do and what my original questions were. Here goes:

I am interested in developing web applications comprised of two main architectural components: a client, and a server. 

The client component consists of a definable set of HTML files, CSS files and JavaScript programs that run in a web browser.  

The server component is comprised of the following architectural components: a web server, a CGI program, and one or more data resources (e.g., DB2/400 database files, IFS stream files, data queues, data areas, spooled files).  

The web server together with a particular CGI program constitute a service that allows the client to access data resources. This is not a web service. However, it is a service, and it is consumed by a browser client using HTTP messaging over a network.

Communication between the client component and the server component via a service can, but does not have to, conform to REST architectural constraints.

My original questions were how to handle authentication and authorization in this kind of web application while conforming to the statelessness constraint of REST.

I hope that is a little clearer (if somewhat more "definitiony"). No more use of the term web service.

Thanks,
Kelly


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

Kelly,

I feel a little badly about responding to this thread because I abandoned the CGI interface about 15 years ago. I'm torn between recommending a license to our web portal, or just dropping out of the discussion to let others explain the nuances of CGI interfaces.

The program you use to authenticate users against your LDAP directory, which is the entry-point into your "system", needs to place "something"
that represents each user's "authentication state" in a browser cookie, or a query string parameter, or some kind of "session" object on your server, which could be accessed by any CGI program which might be subsequently called.

That begs the question - must every CGI program called subsequently check the user's "authentication state" for each an every subsequent request?
I'll leave that to others to explain.
--
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.