Kiss (Keep It Simple Stupid - KissPrinciple
) web services are techniques to make simple web-based communication between two or more machines without blowing a wad of cash or hooking in a trendy but fat framework.
One Kiss approach is to have a "Get" call with parameters that returns delimited information (delimeters can be commas, pipes, tildies, etc). Delimiters are usually easy to parse.
name | category | amount // first row is (optionally) column titles
here | there | 77.20
foooo | barrr | 22.99
zack | smack | 62.05
If you want to be BuzzwordCompliant
, then perhaps try:
<result name="here" category="there" amount=77.20/>
<result name="foooo" category="barrr" amount=22.99/>
<result name="zack" category="smack" amount=62.05/>
The interface can have a predicate feel to it:
Another approach is to send SQL
as an HTTP "post". The server then executes the query and formats the results with CSV-style delimiters or pipes or whatnot. For illustration purposes, let's look at an HTTP "get" version of such:
// comment: GET version for illustration only. Production would be POST
(Assume URL space encoding instead of underlines)
The downside is that this complicates security concerns
, as more attention needs to be paid to the user access levels on the various tables or views. It would be more appropriate for intranet usage than a public website.
Using URL parameters perhaps could be called a form of PredicateDispatching or textual QueryByExample, assuming that some or all of the parameters are optional. However, the downside is that it may lead to open-ended queries. Perhaps a miximum number of records should be returned. Some approach may be needed to notify the user that the threashold has been exceeded, unless we rely on just the documentation alone to state the max. An alternative is to require certain parameters, such as a specific retail store location (store_ID) so that it is not possible to query every store. This would ensure that in the worse case, only every record from the largest store is returned, which would be say a few thousand records, well within practical limits.
http://www.example.com/myroutine.prg?store_id=7&product_id=4 // valid
http://www.example.com/myroutine.prg?product_id=4&shift=night // not valid
If we wanted to get fancy, we could make at least one of store_id or product_id be required. Querying the inventory levels of a given product across all stores may be an acceptable query. If you have say 5000 stores, then you would get at most 5000 records. (Related: ResultSetSizeIssues)
Subject of Adam Borsworth talk in Nov04 "International Conference on Service Oriented Computing" can be accessed at http://www.adambosworth.net/archives/000031.html
He has reminded people the dispute between SoapProtocol
vs its predecessor of XmlRpc
has not really settled.
Some quotes from that article on the speech:
- <The value of computing> is in the content and the software's ability to find and filter content and in the software's ability to enable people to collaborate and communicate about content (and each other).
- The currency of reputation and judgment is the answer to the tragedy of the commons.
- it is the human side, the flexible side, the organic side of the Web that is going to be important and not the dry and analytic and taxonomical side, not the systematized and rigid and stratified side that will matter.
- As you add value, add it in ways that are simple, flexible, sloppy..
The speech also got responses from Don Ferguson of IBM, but not TimBernersLee
; both were speakers at that conference and referenced in his speech.
RichInternetApplication getting richer, as demonstrated by the technology behind Googles
talked about his experiment to integrate "online bookstores" and "online libraries", at http://www.infoworld.com/article/02/12/17/021219opwebserv_1.html
How is this any different from RepresentationalStateTransfer
Cheeky answer. How so? More importantly, how is it you are distinguishing KissWebServices
such that you can be certain they are not
the same technique and thus declare one 'simpler' than the other. It is illogical to say "X is 'simpler' than Y" without first establishing that "X is different from Y". The person who asked the question clearly suspects KissWebServices
is the same as REST, and so finds your claim 'illogical'.
For example, here's a passage from a link that's in the REST topic:
Create a URL to each resource. The resources should be nouns, not verbs.
For example, do not use this:
Note the verb, getPart. Instead, use a noun:
(end quote) // Dots to work around FireFox/Mozilla C2 space bug
My original suggestion above does not put any such restrictions. And, one cannot naturally create predicate URL's that way. Now for some shops or existing apps perhaps it's easier set up the way mentioned in the quote. However, "it depends". Predicate URL's seem the simplest to me, but I don't know your particular shop. I strive to describe KISS here, not dictate standards.
Is it your thought that avoiding standards simplifies things? My understanding is that, in general, you need to trade between 'simple to use' and 'simple to create'. It is 'simple' to create systems without standards, but standards make a system 'simple' to use or integrate with after they have been created. Which of these aspects do you aim to keep 'simple' by avoiding standards?
I would say "it depends". Anyhow, I lean toward "simplicity in construction and understanding" here. Using REST appropriately requires some up-front investment in standards study and planning. I could walk up to just about any web developer and describe the above in about 5 minutes and they could pound it out in an hour or two. Further, if the standard does not offer anything of net benefit, then perhaps its not needed. Not all standards are good standards.
I agree that not all standards are good standards. though 'net benefits' are always relative to other standards. What makes you believe KissWebServices
is a good standard that offers net benefits over, say, REST? Can you support an assertion that there is a net benefit to investment time in standards study and planning prior to application?
For one, it's easier to describe.
Point to you, but "C
haosWebServices - do whatever you want, cross your fingers, and hope for the best" is even easier to describe, and I can't imagine it offers many net benefits over REST.
I do not know what kind of problems you are envisioning. Details please.
Your earlier reply was insufficient. "KissWebServices is easier to describe"
is not a sufficient answer to the question of "What makes you believe KissWebServices
is a good standard that offers net benefits over, say, REST?" Nor is it a sufficient answer to "Can you support an assertion that there is a net benefit to investment time in studying KissWebServices
prior to applying it?". As such, saying: "it's easier to describe"
is at best a distraction, at worst a red-herring. I'm sorry to have vastly overestimated your reasoning skills in assuming that you would take a simple analogy (ChaosWebServices - easy to describe, offers no benefits
) and reflect long enough to compare it to your prior answer.
I feel I'm being harassed merely for the sake of harassment by the same person who has harassed me before. I'm happy to LetTheReaderDecide at this point. -t
Rest is based on XML. KissWebServices
can easily use comma-delimited, which is generally more compact than XML because it is position-based instead of key-value-pair based. Thus, it may be a nice option if bandwidth is limited or expensive.
REST is an architectural approach; it is neither a standard nor a specification nor a language. It does not mandate XML.
See also: RelationalAlternativeToXml
CategoryMessagingServices CategoryWebServices CategoryLowEnd CategorySimplification CategoryCommunicationProtocol