[FoRK] SOAP vs REST

[Stephen Williams]

silky wrote:
> On Fri, Apr 11, 2008 at 5:31 PM, Stephen Williams <sdw at lig.net> wrote:
>   
>> silky wrote:
>>
>> ...
>>  What strategies will you use to be architecture, language, operating
>> system, storage type, character set, etc. agnostic and tolerant?
>>     
>
> uh huh, will storage type i don't care about, character set is just utf-8.
>
> [i'll keep answering in segments but i have a main point later]
>   
So you're already converting data, serializing and deserializing.  And 
you need identification, structure, framing, encoding/decoding rules, 
whether those are explicit in the format or implicit in the code at each 
end.

XML isn't perfect but solves a lot.  EXI (W3C's Efficient XML format) is 
better, but still not there.  I argue from the point of view of EsXML 
2.0 (EXI + missing features + optional in-place random access / 
modification and deltas = my overdue thesis).
>   
>>  What about versioning, exceptions, old code still working with data from
>> new code with new features, etc.?
>>     
>
> sure it's trivial enough and solved with or without xml; just mark the
> version of the interface [if you like, not a requirement] and
> implement on either side appropriately.
>   
Gack...  Are you going to keep hundreds of versions of the code around 
to deal with all of your revisions?  What about multiple simultaneous 
revisions by many different parties?  What about old code still working 
on data from new code?

Versioning, at least very fine fragile versioning,  quickly becomes 
untenable.  Almost immediately in many cases.
What's a good counter example?  How about RFC822?  It was published in 
1982.  There are thousands of implementations and at least hundreds of 
"versions" of expansions to that standard, and still an MTA and mail 
reader from 1982 can reasonably read and write email with current 
systems.  I'm not happy until I can architect systems with that level of 
stability and unlimited compatible expansion.  Sure, some interfaces / 
protocols don't need that.  The great example is TCP/IP.  Most 
application situations are more like the former than the latter, at 
least until they fully mature.

XML allows you to get there to some extent.
RDF (by which I mean any complete encoding of an RDF/RDFS inspired / 
compatible n-tuple graph representation of data/metadata) is a better 
way to go in the long run. 
>>  And will your data be decipherable without the code in 20+ years?
>>     
>
> well data is irrelevant in my case because i have the data, he has the
> data, we're just exchanging it. my data in my database is pleasant and
> makes sense to me. his data is nice, i suppose, and is meaningful to
> him. the interface matters little in this; and infact a worse/heavy
> interface could suggest/require more annoying/redundant data.
>   
First, relational database representations of data are incomplete, and 
as far as I'm concerned, a dead method as a prime data model.
Relational databases themselves are useful, but as indexes or lower 
level building blocks of a proper model.
Why?  Because the great flaws are:
  o relationships are implicit by design
  o RDBMS's have uniformly stuck with fixed tuple representation, even 
through the first generation of XML support.

What we are now moving to are graph database management systems (GDMS?)  
SparlQL (plus OWL etc.) is a pretty good try, although the extended 
capabilities by implicit reasoning layers design seems a little hoaky to 
me.  GDMS's can be implemented as a model on top of RDBM's, and they 
are.  The best implementation has yet to be determined.

Anyway, my preference is for the simplest API / interface possible, 
although I want XML-ish, and RDF/OWL-ish, capabilities.
>   
>> Or are
>> you going to have two completely different methods of storing data to file
>> systems vs. databases vs. interacting with other modules, programs,
>> services, servers, etc.?
>>     
>
> eh?
>   
OK, that's on a whole different architectural plane I guess.
>>  Conventional wisdom often isn't. "Best practice" is often best practice by
>> beginners and other Shallows.
>>  Real best practice is used by Deeps doing real architecture and design.
>>     
>
> hell yes.
>
>
> okay now my point i suppose. flexible small interfaces [non-xml
> rest-like] are nice because they are (oh god someone stop me using
> this word) "agile". they let you get things done quickly and carry on
> with important business; not a damn interface. and in carrying on,
> further features can be added in a more effective way, more interface
> contracts, etc.
>   
To the level of sending named parameters, and even getting back named 
parameters, this is reasonable.  But of course XML gives you that 
trivially, plus the ability to expand in most directions.  RDF et al 
give you total flexibility.
> to me when you get to xml you spend a lot of time screwing around;
> xslt that, namespace this, dtd there, some-other-thing there, it's
> just annoying. basic is where it's at.
>   
DTD's are verboten as far as I'm concerned.  Dead.  Stupid.  Bad idea.
xslt is interesting, but I would only use it in narrow circumstances.
Namespaces are fine, but you typically only need one or two for an 
application.  There isn't much to it, just name scoping.  Since URI's 
are the W3C's answer to GUIDs, and they are better, you need some way of 
avoiding long IDs everywhere when you want to uniquely specify identity 
and typing.

And you don't need a schema.  In fact, I don't like schemas for a range 
of application communication.  [Long discussion deferred.]

And most XML frameworks and APIs are broken, verbose, inefficient, and 
just not right.  Some are getting there now.
Mistakes were made in designing most of the APIs.

What's a good API?  How about this:

Message m = new Message("message");
m.set("buyer/firstName", "Bob");
m.set("buyer/lastName", "Jones");
Message item = m.scope("items/item[0]");
item.set("sku", 12345);
item.set("price", 34.55);
item.set("count", 3);

(Of course you can have even more concise versions, or additional methods.)

...

nitems = m.count("items/item");
for (int x=0; x < nitems; x++) puts(m.get("items/item", x));

No other code, metadata, schema, or preparation needed and it reads and 
writes standard XML.  (I designed this and we implemented it on top of 
DOM in 2001/2002.  I called it sdom.)

In fact, you can have a data format that doesn't need serialization or 
parsing and can optionally encode data as portable binary scalars that 
uses the same API.  That's esxml / esdom.

sdw