Kiss Web Services

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.

Example input: 

  http://www.example.com/myroutine.prg?foo=7&bar=4
Example output: 

  name | category | amount   // first row is (optionally) column titles
  here | there | 77.20
  foooo | barrr | 22.99
  zack | smack | 62.05
  etc...
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/>
  etc...
The interface can have a predicate feel to it: 

  http://www.example.com/sales.prg?store=7&productID=4


  http://www.example.com/sales.prg?store=7&clerkID=32


  http://www.example.com/sales.prg?store=7&format=summary
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
  http://www.example.com/sales.prg?sql=select_*_from_foo_where_id=7
(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.

-- top

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)

KeepItSimpleAndSloppy WebServices

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 speech also got responses from Don Ferguson of IBM, but not TimBernersLee; both were speakers at that conference and referenced in his speech.

Spontaneous Integration

RichInternetApplication getting richer, as demonstrated by the technology behind Googles

Dec02 JonUdell 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 techniques?

Simpler

Cheeky answer. How so? More importantly, how is it you are distinguishing KissWebServices from RepresentationalStateTransfer 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: 

  (begin quote)
    Create a URL to each resource. The resources should be nouns, not verbs. 
    For example, do not use this:
    .
        http://www.parts-depot.com/parts/getPart?id=00345
    .
    Note the verb, getPart. Instead, use a noun:
    .
        http://www.parts-depot.com/parts/00345
    .
  (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 "ChaosWebServices - 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

Bandwidth?

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, OpenDataBaseConnectivity

CategoryMessagingServices CategoryWebServices CategoryLowEnd CategorySimplification CategoryCommunicationProtocol CategoryArchitecturePattern?

EditText of this page (last edited August 14, 2010) or FindPage with title or text search