×
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.
From: Richard Schoen
To me RESTful is anything where I can pass a formatted URL with parms
of some sort and get data back 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 by using URLs.
3. Metadata is passed as name-value pairs.
After that, it's easy to fall into debates about adaptations, coding 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 middleware, frameworks, toolkits, and runtime environments.
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, 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
midrange.com
