|
Richard you didn’t. We have just had a long discussion on LinkedIn (that never seems to stop) about REST and CRUD where some interpreted the REST and CRUD very strict while others (me among those) had a more pragmatic interpretation. These acronyms stand for architectures that are 10-20 years old while in the meantime the world has moved to both UTF-8 and JSON based web-services that may be interpreted as “STATELESS WEB-SERVICES with strong unspecified similarities to 80% REST, 80 % CRUD, 80% RPC and 80% SOA with a twist of SOAP done in JSON and that also may pass Code On Demand”. To me it gives no meaning to encourage implementing REST in a strict interpretation. Just the use of HTTP header methods like PUT, POST, GET and DELETE simply won’t cover the methods in a more sophisticated web-service and using the directory part of the URL to pass parameters such as …/custno1234 will restrict the parameters to 7 bit ASCII where parameters today in 90 % are passed as UTF-8 encoded that the directory path doesn’t support but the URL parameters ?custno=1234 supports. Neither does SOAP since it primarily is used to exchange server to server information and not client to server information. But SOAP is also a XML based architecture very similar in structure to X12 and EDIfact envelope construction where JSON is much more slim and lightweight. Besides that a pure REST or SOAP environment will normally run in their own WEB domain and thereby outside the browsers and servers primary WEB domain and will thereby be unreachable from the browsers AJAX code. You may reach them with a FORM request but most browsers only supports HTTP methods GET and POST in their forms. Therefor it doesn’t really make sense to me to skip 10-20 years evolution and discuss implementation of pure REST. On Fri, May 15, 2015 at 9:44 PM, Richard Schoen < Richard.Schoen@xxxxxxxxxxxxxxx> wrote: > Did I confuse you or something ? > > Don't give up. We need you :-) > > 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: Fri, 15 May 2015 15:32:37 +0200 > from: Henrik R?tzou <hr@xxxxxxxxxxxx> > subject: Re: [WEB400] IBM i authentication and RESTful web service > design > > I give up ... > > any technology in a STATEless environment has to deal with some kind of > STATEful design to mimic a session. > > On Fri, May 15, 2015 at 2:28 PM, Richard Schoen < > Richard.Schoen@xxxxxxxxxxxxxxx> wrote: > > > To add to Scott's comments, when you set up Apache for SSO, the AD > > auth user gets populated with user@domain so your app code can use > > that info to determine if the user is logged in correctly if you need > > to check the user name. > > > > Personally I also like to cache session state in the database and > > assign a session ID that expires. Then the browser or smart client app > > only needs to hold the session ID locally when it's doing its > communication. > > > > 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: 6 > > date: Thu, 14 May 2015 23:41:38 -0500 > > from: Scott Klement <web400@xxxxxxxxxxxxxxxx> > > subject: Re: [WEB400] IBM i authentication and RESTful web service > > design > > > > Kelly, > > > > If you have SSO already set up (such as LDAP, etc) then you can > > configure Apache to use it. You would add something like this to your > > config file for LDAP support: > > > > LoadModule ibm_ldap_module /QSYS.LIB/QHTTPSVR.LIB/QZSRVLDAP.SRVPGM > > > > <DirectoryMatch "^/QSYS\.LIB/YOURLIB\.LIB/[a-z0-9]*\.PGM"> > > LDAPConfigFile /www/YOUR-HTTP-INSTANCE/conf/ldap.prop > > PasswdFile %%LDAP%% > > AuthType Basic > > AuthName "Kelly's Service" > > Require valid-user > > </DirectoryMatch> > > > > > -- > 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 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.