I agree with the RESTian argument that SOAP-accessible web services should support HTTP GET where appropriate. The notion is that this will help ensure low coordination costs both for person-to-machine as well as machine-to-machine communication.
In TAG Finding: URIs, Addressability, and the use of HTTP GET , Dan Connolly sums up the recommendation that resources be made URI-addressable where possible, and dispels two myths that have clouded the issue:
- Myth: Search services will not index anything with a "?" in the URI.
- This was a heuristic to avoid infinite loops in some search service crawlers, but it was not an architectural constraint, and modern search services use more sophisticated heuristics to avoid loops.
- Myth: URIs cannot be longer than 256 characters
- This was a limitation in some server implementations, and while servers continue to have limitations to prevent denial-of-service attacks, they are generally at least 4000 characters, and they evolve as the legitimate uses of application developers evolve.
How this relates to the orchestration of web services is still very unclear though. Consider this remark on the TAG mailing list , from Edwin Khodabakchian, CEO of Collaxa :
- we need to acknowledge the fact that we are solving a new class of problem that is more about machine-to-machine communication
Perhaps this really is a new class of problem, but if so I would like to see spelled out more clearly exactly how and why that is so, and what it implies.
Former URL: http://weblog.infoworld.com/udell/2002/06/17.html#a303