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
As an Amazon Associate we earn from qualifying purchases.