[FoRK] SOAP vs REST

[silky]

On Sat, Apr 12, 2008 at 3:27 AM, Stephen Williams <sdw at lig.net> wrote:
> 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?

all interesting problems but i don't see why an xml structure solves
these when a plain structure doesn't?

in our case versioning is way beyond any requirement we have. the
interface is so simple that it's useless.

in another interface we have, i am embedding the version in the first
part of the protocol [again this one is not xml, but some length-based
scheme for other architecture]. so we have the version there, and can
implement concepts around it if we need to.


> 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.

okay, that can be your opinion, [disagree or agree as i may] but i do
find in my case that the db is fine and accurate and a nice
representation of the real environment. it's trivial, via some
queries, to match things up and get nice result.


>  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.

can't say i'm familiar with gdms/owl etc so i can't comment on that.


>  Anyway, my preference is for the simplest API / interface possible,
> although I want XML-ish, and RDF/OWL-ish, capabilities.

i rarely want xml [depends on the amount of fields & instances of
those] but yes simple api is best.

i mean one can even argue that xml should not even be compared to
simple rest; rest is for ACTIONS, xml is for DATA [multiple rows].


> > > 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.

but xml is annoying in some languages. [i.e. i proposed xml as one of
our interfaces, but was shot down by the other party due to his
scripting environment].


> > 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.

why only narrow? i am now trying to format/process an fxcop report. i
went to their namespace and found the link is dead [ms retired
gotdotnet] so now i am just going to make up an xslt sheet and
transform it myself to html, because it's the fastest way over parsing
it manually [i guess], but it's still annoying.


> 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.

i personally have uri's as GUIDs, but that's just me maybe.


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

pending that discussion i may agree with you.


> 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.)

yes, for an xml-generating api that rocks agreed. most xml api's
really suck; and perhaps if we were to get better ones life would be
better [lets not discuss crazy embedded xml in ].


>  ...
>
>  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.

hmm sdom + ajaxy ..... (sdomy)


>  sdw


-- 
/babblebot

http://lets.coozi.com.au/

There's not a problem I can't fix, because I can do it in the mix.