Will it scale?
2003-09-26 03:04:20 Brian Ewins
"Would it be able to handle complex datatypes and binary data?"
This reminds me of the old chestnut of someone asking "What's the Gaelic for spaghetti?" only to get the reply "What's the English for spaghetti?". SOAP handles complex data types and binary as text representations - Mark's REST version of the service would encode the complex data types and binary as, erm, text representations...
"And long method invocation strings? Aren't URIs limited in the number os chars they can have?"
The limit isn't one you'd run into in normal circumstances. You are thinking of the old days when CGI was converted into arguments on the command line for a script.
Another more pertinent argument is, queries generally don't need to scale up that much (GET requests = queries) - I'll cite the "html web" as evidence of this. Obviously, in these cases, the authors have achieved something that is cacheable and addressable by designing within the restrictions of an URL.
An implication of that statement is that, by using SOAP+POST for queries, the authors reason is one or more of:
a) working on a "minority case" problem
b) deliberately disabling caching
c) deliberately disabling addressability
d) other restrictions (toolset, management, other devs) made SOAP+POST more practical
e) unaware of the issues
f) just following the herd
g) too lazy to actually design the service
NB There are fine, valid reasons in that list, and I only got to the "namecalling" ones when I ran out of ones by which the author could /justify the choice/ of SOAP+POST over a GET based service.
- Will it scale?
2003-10-23 15:16:55 David Byrden
>> Mark's REST version of the service would encode
>> the complex data types and binary as, erm, text
>> representations.
In what format? URL-encoded XML? How easy will that be to edit by hand, since editors for URL-encoded XML are not thick on the ground?
On the programming side, putting the output of an XML serializer through an URL encoder would not be difficult; just pointless.
Sorry, but having data in an URL instead of XML makes sense only when the data format is trivially simple.
David
Previous Message
