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



XMLSERVICE WITH JSON SUPPORT:

http://216.109.205.54:8080/iapp.html


On Sat, Jan 28, 2012 at 3:53 AM, Richard Schoen <richard@xxxxxxxxxxxxxxx>wrote:

Nathan,

It is OK to produce and consume web services that vary from WSDL and SOAP
:)

We have used our own RESTful / URL based services for years to offload
processing requests from the iSeries to other servers, even before REST was
defined as a term.

It's quite easy to define your own data exchange request/response
protocol. It's really no different than using Sockets programming, you're
just using HTTP as the transfer protocol.

Based on your comments in the WEB400 forum though it sounds like you have
a bigger problem because you'll be expected to conform to some specific XML
standards with your apps.

That's a bigger can of worms :)

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx<mailto:richard@xxxxxxxxxxxxxxx>
Web Site: http://www.rjssoftware.com<http://www.rjssoftware.com/>
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT

-------------------------------------------------------------
From: Richard Schoen
To me RESTful is anything where I can pass a formatted URL with parms
of some sort and get data back<
http://archive.midrange.com/rpg400-l/201201/msg00260.html> in XML, JSON
or whatever format I desire.


That sounds pretty good. If I had to reduce the original dissertation on
REST to just 3 short sentences, I think the following captures its essence:

1. Resources are requested via URLs.
2. Protocols are limited to what you can communicate<
http://archive.midrange.com/rpg400-l/201201/msg00260.html> by using URLs.
3. Metadata is passed as name-value pairs.


After that, it's easy to fall into debates about adaptations, coding<
http://archive.midrange.com/rpg400-l/201201/msg00260.html> conventions,
and best practices.

One of the things I'd like to get out of this discussion, and I've touched
on this in previous posts, is that it is okay to produce and consume web
services that vary from the WSDL & SOAP specifications which have become
"recommendations", and supported by IBM and Microsoft<
http://archive.midrange.com/rpg400-l/201201/msg00260.html> middleware,
frameworks, toolkits, and runtime environments<
http://archive.midrange.com/rpg400-l/201201/msg00260.html>.

We need specifications and terminology that ordinary people can
understand, easily. Web service producers and consumers need this.

REST might be an answer, or part of an answer, because it focuses on URLs,
URL based protocols, and passing meta data as name-value pairs, which is
the essence of the Internet.

Otherwise control of web services shifts from ordinary people to those who
buy into the most prominent middleware, frameworks<
http://archive.midrange.com/rpg400-l/201201/msg00260.html>, toolkits, and
runtime environments. We need an environment where people are not "shamed"
into going along with specifications and protocols that are overly complex,
have too much overhead, and require too many resources.

-Nathan
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.





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.