On 12/13/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> REST is just "in principle" sending a bunch of data to a method
> (URI/(PUT/GET/etc)) which invokes business rules with data.
So, basically, in principle, they're doing the same stuff; giving
geeks a means of living. And, they are two different approaches to the
same stuff. And, technically you can do exactly the same in both
technologies. And, it's in the eye of the beholder as to which design
you reckon is the best for you and yours. Agreed?
> > And I hope you're not suggesting that OO
> > hides complexity better than good ol' procedures? :)
>
> Most research that I read in the 90s indicated that it did, and
> certainly the maintenance costs of OO appears to be less than
> procedural. So yes I would.
Well, IMHO it really doesn't. OO in itself does not hide *complexity*,
even though it is claimed it hides implementation details, but,
frankly, I'm not so sure about that one either. OO as a style of
programming has its goodies, but it also has a few flaws, just like
functional, declarative (my favourite) or otherwise ways of enabling
us to express ideas in computational ways. I see more abstract misuse
of the OO prardigm than I saw too many functional expressions of
similar ideas. Crap in, crap out, and all that.
> > Actually, the dynamically REST system we've got only gives you
> > contextual endpoints, and as such does not require you to know about
> > state at all in a lot of cases.
>
> I need to re-read that REST paper, I'm sure it talks about the client
> owning the state (hence PUT).
State is an interesting beast, as we keep on mixing up state of
objects, state of transfer, state of clients and the state of the
world in our various examples. I guess what I'm trying to say is that
one can use REST to reduce the impact and knowledge of state (the
resource in itself changes the interface as the state changes).
> > * Guaranteed GET for all resources (with content negotiation if you
> > want it;
[...]
> Which for someone such as yourself is great, do remember that the
> majority of IT people out there get the screaming heebie jeebies when
> they see XML, they NEED the nice IDE.
Really? I must say I'm a bit stumped on this one. Can you explain? In
my world, if you don't know your XML and if you don't grok it, you
can't call yourself a developer of anything these days.
> Its a very sad fact about IT
> but I'm 100% certain that the average technical level of developers is
> not as high now as it was 10 years ago (probably higher than 5 years
> ago but that is because in the .com boom people who could spell HTML
> three times in five were given a job).
I can agree with that one. :)
> > * The resource orientation itself (I don't need to know how to invoke
> > the "object", only how to use it) which also makes you think in
> > different semantic terms than objects (more structure and taxonomical
> > relationships), which is compatible with how most people on the planet
> > uses URL's.
>
> Objects are great for the medium and the small, Services work for the
> large, I'm still struggling with a simple resource oriented model for
> a complex supply chain which will work in the way the business
> operates.
But people - normal people out there, not wierdoes like you and me -
don't know what an object is, but they *have* heard about and use URLs
in their browsers. I suggest that perhaps there is something about
these URLs that work? :)
Also, as much as I don't think taxonomic thinking saves the day, it
will certainly get us 80% through it, purely by its
breadcrumb-friendly nature that almost eliminates the need for the UML
evils that plague the enterprise world.
> > * URL's are free; they can be bookmarked (by browsers as well as
> > applications and tools), which helps in exposing your design (both
> > semantics and schematics) and hook people in (GET is easy; it somewhat
> > becomes part of your documentation)
>
> "somewhat" is a bit optimistic, its like the "code is the
> documentation" mantra that makes people think commenting is a bad
> thing.
No, it *is* documentation in that the GET might deliver a nicely
looking web 2.0 compatible AJAX-friendly rounded-corners funky piece
of document that, indeed, is the documentation. :) For example, with
our resolver, if you do soa.domain/find/ with a browser you are
forwarded to our Wiki that has all the documentation for that service.
If your application uses the same URL but can grok our
application/x-funky-chicken MIME type, they get an XML in the
funky-chicken schema used in our SOA, and if you can grok the
application/xml+atom you can get an Atom feed of the latest searches
going through the service. If you use soa.domain/find/monteverdi in a
browser, you get a nice-looking XHTML representation (but we use a bit
of microformats in there as well for good measure), if you use the
funky-chicken MIME, you get it all in that XML representation
(including FORMs interface), or xml+atom gives you an Atom feed for
that search. Same URL, different uses. This becomes very important as
your services expands; no need to republish WSDL and somesuch to
rewire your application; you browse around the functionality of a full
application, and when you find the representation you need you switch
the content-negotiation and start working with it straight away. Maybe
this way of working sounds dreadful to you, I'm not sure, but to me
it's a huge time-saver as the application for humans and the one for
computers can essentially be the same. Even if humans don't normally
traverse through a workflow using a web interface doesn't mean it
doesn't make sense to still do it from a debugging and development
angle. Maybe it sounds like too much work to create a service point,
but I've found over the years that if services aren't groked by
people, the service mostly is useless even to computers.
> The fact is that nice shiny IDEs are what these people need.
Can others verify that this is true? it sounds pretty crazy in my
ears, but maybe I'm living in a fantasy world where people have to
know what their technology is and does. :)
> Machine readable APIs.... I've been asking for that but nothing has
> been forth coming... a pointer would be great.
<form action="/service/users" method="GET">
Gets list of users
<input type="submit">
</form>
<form action="/service/users" method="POST">
Adds new user
<input name="full_name" type="text" cols="40">
<input name="username" type="text" cols="20">
<input name="password" type="password" cols="20">
<input type="submit">
</form>
And so forth. State changes the returning forms, of course. But, on
the other hand, you're looking for *formal* committee-approved,
bodies-embraced pointers I'm not the right guy to help you out. :)
Maybe some others have some pointers. I'm currently investigating if
my efforts are worthwile digging into XForms, but I'm feeling less and
less sure about that monstrosity, although it does give you XML Schema
and validation.
> > * Based on technology that's been around for yonks, and is proven to a
> > large extent in terms of reliance and scalability, and the technology
> > specifically is much, much larger than service orientation alone (if
> > you're into WS-*, you're into service orientation; REST grapples with
> > much more than that) which means more people have expertize in various
> > aspects of it.
>
> I've been into SOA since before WS-*, SOA has NOTHING to do with the
> technology implementation in my book.
You got that back to front, as we basically agree. I said if you're
into WS-*, then you're into service orientation, as one way to work
within it. SOA is definitly not about technology.
> > I think a lot of people struggle with the lack of strong typing as
> > being part of the "API" as such (or, the resource orientation), that
> > you have to glue a bit instead of having the stack deliver things back
> > to you in strong typed ways. But is this a technological limitation,
> > or just a personal preference?
>
> TCO, strongly typed languages tend to be cheaper to maintain IME.
Well, I guess it depends on who you ask. They are usually thought to
be faster because it's preoptimised for validation, but I'm curious as
to what level of throughput that is truly true and what the
duck-typing (and other means of loose typing) costs in times of not
only performance but maintainence and development time as well.
> The main reason for that is that the majority of IT people don't have your
> ability.
Can't really argue with that. :)
Regards,
Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __________________________________________________
