Steve Jones wrote:
> On 9 April 2010 18:20, Stuart Charlton <[email protected]
> <mailto:[email protected]>> wrote:
> Close. SQL is similar in its generality at the language level, but
> has flaws in the supporting infrastructure. It requires much
> deeper ties to the data model to understand how to enact proper
> state changes (e.g. to order a book, I have to know what table(s) to
> insert into, vs. in a Web Service, I can call a method signature, or
> in a REST interface, I can follow hypermedia that eventually leads
> me to a POST/PUT resource where I can order the book if I can
> generate the proper representation(s) to transfer).
>
>
> Ummm but is that the reality? I'd argue that a REST interface has a
> poor supporting infrastructure around this as well as without decent
> service documentation then I don't really have a clue about what each
> element means and what the structure of the return elements mean. There
> is no Mime type for order book so you have to work it out yourself. At
> least with SQL there would be a published data model.
>
> Theoretically I agree with you I just think that practically this isn't
> the reality.
When I think about SQL vs REST, I think of differences between things like XML
vs CSV formatted text. With SQL, there is limited set of knowledge you need.
You can formulate queries and understand the expected results because you've
spelled out the details in your query parameters for example. With XML, the
structure is there to guide you in accessing the content, but the content is the
value, not the container for the value. A CSV file, is another type of
container of values where a lot more information is needed, even though there is
some obvious information in the form of the separator chars, lines etc.
REST is more like a CSV file in that there is only a small amount of "known",
where as SQL is more like XML in that there is more visible structure that helps
you understand what is there.
When you look at REST as a solution space, it's a very sparse and spread out bit
of detail that doesn't, in that view, seem valuable because so little is
actually "fixed" with meaning.
I think Steve is talking about this kind of difference. SQL has lots of known
stuff, like XML where as REST, like CSV, has standards and practices, but there
is so little mean on the bones which spread out over quite a few pieces of IT
space, that it's hard to see "where" value is, and many people have a hard time
grasping the details because so little is actually "visible" as "value added".
> Most concurrency today is handled with toolkits or frameworks that
> separate the concurrency management from the business logic. I
> think the same will need to happen in the area of interface
> resolution to make dynamic interfaces successful. I have some
> ideas here if I can get to them.
>
> I agree completely, I actually did some Java stuff on this in around
> 2000 using fixed interfaces and dynamic proxies. Time as ever is the
> problem.
Steve probably remembers the details of how the folks at Orbitz and how they
completely reworked the internals of the RMI based jini 1.0 infrastructure to
use nothing but dynamic proxies and reflection based type/argument/signature
mapping.
This was an interesting choice from many perspectives. There was no JERI at
that point, so they didn't have the ability to create and
InvocationLayerFactory
to do this kind of thing at that point. But, now it is possible.
I still tow around the sign that reads RPC is RESTful, because it has a limited
command set, "invoke", and hypermedia in the fact that you might get back a
remote object reference to a remote resource, and not a serialized data object.
But, for some reason, people still think hypermedia has to have <> characters
in
it, it seems.
Gregg Wonderly
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
[email protected]
[email protected]
<*> To unsubscribe from this group, send an email to:
[email protected]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
