Tag: webservices

Search API Shutdown

Google is protecting its cash cow (search+advertising) by turning off the direct data pipe to search and requiring that you use their library to mediate. Like it or not, it’s their data after all and they can do what they want with it. What’s ironic is that we just spent God knows how many engineering dollars putting an open protocol head (SOAP) on one of our cash cows (Windows).

pretty good discussion on the google soap api shutdown, with comments from markl: The search results we provide are just as rich, if not richer than whats provided by the SOAP API.

enabling web services

a well-written paper that offers 13 principles to follow.

  1. Every data record and collection is a resource.
  2. Every resource should have a URI.
  3. Cool URIs don’t change.
  4. Data queries on existing resources should be done with a GET.
  5. Use POST to create new resources.
  6. Preserve the structure of data until the last possible moment (i.e. return XML).
  7. Make XML Schemas available online for your XML.
  8. Make data available in multiple flavors.
  9. Use Metadata (RDF) for XML.
  10. Document your service API using WSDL, WRDL, or some other standard.
  11. Advertise the presence of the data using WSIL.
  12. Adhere to data standards such as RSS where available.
  13. Use HTTP authentication as much as possible.

soap on apache

i am digging into soap now, and it’s a mess who would have thought that installing soap on apache were such an undertaking? since soap for apache is basically donated java code from ibm, it of course relies on the entire java framework for apache being present.

1 thing i always hated about java was the incredible mess it had with all its 100s of directories, 10s of config files, $CLASSPATH and so on. now while many open source projects have not exactly been known for good documentation (perhaps this “lesser task” is beneath self-declared hackers) it seems to be worse with open source projects in java.

anyway i did not have the nerve after a full days work to read up on all these arcane details i frankly could care less about. so no soap for apache today.

competing with .net does not just mean whipping together a soap stack and create some bindings for php, perl and python. web services is about leveraging infrastructure to get quick results. if you have to fiddle around with configuration details you could just as well skip web services. there is a strong need for a ready to run soap package where everything is already neatly configured and integrated. you should be able to have a hello world up and running in minutes. that’s what they deliver today on the microsoft side of the fence.