Re: 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
>