Re: IBM i authentication and RESTful web service design

Hi Richard,

>> My definition of REST:
>> Any app that can respond to HTTP calls :-)

I see the smile... but I believe some people are starting to think that REST simply means "using HTTP for the API communication protocol."

I have no problem with this. I'm not married to the REST architectural style. 

At the same time, if people who are unfamiliar with REST learn that REST just means using HTTP as the API communication protocol, then they won't understand the benefits and tradeoffs of implementing the various architectural constraints that were original grouped under the acronym REST. 

And if one doesn't care about the benefits and tradeoffs of REST architectural constraints, then why bother using the REST acronym at all? One could just as easily say HTTP, which would be more familiar and more precise.

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Monday, May 18, 2015 12:20 PM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] IBM i authentication and RESTful web service design

My definition of REST:

Any app that can respond to HTTP calls :-)

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: 1
date: Mon, 18 May 2015 14:38:57 +0200
from: Henrik R?tzou <hr@xxxxxxxxxxxx>
subject: Re: [WEB400] IBM i authentication and RESTful web service
	design

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