[FoRK] SOAP vs REST

[silky]

On Fri, Apr 11, 2008 at 5:31 PM, Stephen Williams <sdw at lig.net> wrote:
> silky wrote:
>
> > sometimes i think SDW is a bot designed to combine acronyms in a
> > fashion that sounds smart but also remains confusing and impenetrable
> > for those humans who are not familiar with them.
> >
> >
>  Maybe I'm just a Chinese Room?  Come closer so I can read your surfaces.
> (Has anyone else read "Blindsight" by Peter Watts?  The end notes are great!
> Have you read "Being No One"?  He references it as a "the tougest book I've
> ever read ... also contains some of the most mindblowing ideas I've
> encountered...   Most authors are shameless bait-and-switchers when it comes
> to consciousness.  Pinker...  Koch...  Towering above such pussies,
> Metzinger takes the bull by the balls."  Lol...)
>  http://www.amazon.com/Blindsight-Peter-Watts/dp/0765319640  (Or you can
> borrow my copy.)
>  http://www.amazon.com/Being-No-One-Self-Model-Subjectivity/dp/0262633086
>
>  Anyway, Nordquist has me totally stumped every time he posts...
>  I didn't expect anyone to have the slightest problem with my post, other
> than I have some references to obsolete technology (which became embedded in
> Microsoft software, which I find both amusing and annoying).
>
>
> > anyway, for mine i prefer basic interfaces [rest]. screw xml.
> >
> >
> >
> >
>  And what are you going to send over those interfaces?

well i already integrate with them and i send simple things.


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


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


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


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


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


>  The mainstream press often discovers these real best practices years or
> decades after they have become old hat for those that need them and when
> countless have suffered through inferior methods and finally complained
> loudly enough.  One of the best examples of this is Message Oriented
> Middleware (MOM).  Every few years, it gets rediscovered and tacked on to
> middleware that was designed incorrectly from the start.  To whit: I worked
> with such an architecture at NCR in the 80's for retail systems (registers,
> servers, credit / inventory links, etc. at department stores) on 68020 Unix
> servers and embedded register systems written in Pascal.  (And later at
> Lexis-Nexis and AOL.)  Then it was tacked on to CORBA, late.  And the MS
> server line.  And HTTP, kind of.  Etc.  IBM MQ looks like it is doing it,
> but no, even though it has a messaging API, it's really doing RPC
> underneath!  (On one project, I spec'd a lightweight message queue.  For the
> client, "message queue" -> IBM MQ, for no particularly good reason.  Knowing
> only real message queues, I didn't prevent it.  Predictably, it was terribly
> slow, and clearly the wrong solution on all accounts.)
>
>  Oh, sorry, more acronyms and stories of the past.  Darn, didn't get my AIR
> code written tonight.
>
>  [Timeout reached.  Bot... err..  Programmer exit.]
>
>  sdw


-- 
/end babblebot.

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

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