Re: IBM i authentication and RESTful web service design

Hi Kelly, 

You just did a good paraphrase of my response.

I've been using http API calls since before SOAP and REST were valid acronyms. 

Think about Windows and Java apps calling IBMi CGI programs and also calling to an ASPX page with parameters and running background business logic and returning data via the HTTP stream.  

We've had apps doing this with IBM i and Windows since the mid-2000's. 

While there are new definitions to make it sound cool, using a URL call to interface to business logic has worked well for a long time without formal definition. 

Hence my response that my definition is: 

Any app that can respond to HTTP calls :-) 

Feel free to agree or disagree !!

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: Mon, 18 May 2015 17:51:29 +0000
from: Kelly Cookson <KCookson@xxxxxxxxxxxx>
subject: Re: [WEB400] 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