× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



" I am getting frustrated by the number of people calling any HTTP-based interface a REST API."
Roy Fielding, 2008 (http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven)

Let's forget REST's  client-server constraint, cache constraint, statelessness constraint, layered constraint and code-on-demand constraint. Let's just focus on the uniform interface constraint, the REST constraint that deals with URLs and HTTP. Does your uniform interface use hypermedia as the engine of application state (HATEOAS)?  HATEOAS distinguishes REST services from other services that use HTTP as the API communication protocol.

You can point to a cow and call it a "dog" if you want. They both have four legs after all. And freedom of speech is a wonderful thing. However, for myself, I would like to understand the differences between a cow and dog well enough to know which one I want to make a pet and which one I want to eat.  ;-)

Thanks,
Kelly


-----Original Message-----
From: WEB400 [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Monday, May 18, 2015 1:55 PM
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] 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


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

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.