Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Where the web services will live

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Where the web services will live

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Scotty Logan <>
  • Cc: Grouper Dev <>
  • Subject: RE: [grouper-dev] Where the web services will live
  • Date: Fri, 18 Jan 2008 23:14:57 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

> It's far from even being loose REST; REST is a bit more than "http/xml
> non-soap web services".

Im really sorry we disagree, but the fifth sentence of the REST Wikipedia
entry says this, which is what we are doing (and I didn’t just edit the
Wikipedia to prove my point :) )...

"The term is often used in a looser sense to describe any simple interface
that transmits domain‐specific data over HTTP without an additional messaging
layer such as SOAP or session tracking via HTTP cookies"

Also, I have no idea why the response would be xhtml if you weren’t going to
use a browser, but I guess as you say with the fancy javascript/ajax engine
to compensate for non-browser http, you could do it... also, if you are only
doing process to process communication (and not using browsers directly),
then why not use a GET vs POST or PUT or DELETE? (besides they say you
shouldn’t :) ). With browsers the back button makes you want idempotent GETs
(and if ajax, you don’t have to worry about back buttons)...

Anyways, I think the point is to make it possible for non-soap clients to
connect to the web service, and we are doing that. I understand that
real-rest would be better for you, but since we are supporting soap and
non-soap, and this way involves no more coding/testing/etc to support both,
it is desirable... people want SOAP, and people want REST, and people don’t
want to have twice as much code... so some parts of it aren’t pure... also
I think that if clients ever moved from REST to SOAP or vice versa, it is a
LOT easier if both use the same RPC structures.

> implementation. That's like saying it's OK to use a SQL database
> implementation that doesn't support INSERT or DELETE, but that some
> syntax for SELECT achieves the same result.

I don’t think that a fair analogy... if you don’t have INSERT or DELETE, then
you lose functionality... the loose-rest doesn’t lose any functionality, it
still requires clients with only http and xml, it just isn’t the same layout
as strict-rest...

If we are worried about the coding of clients being harder or more time
consuming for loose-rest, I think my code examples help with that. They are
only a few dozen lines of code, you could translate them into any language
with HTTP and XML-DOM support, and they take very little time to code...

I guess my point is, if we are going to maintain twice as much server code
(to have SOAP and pure rest), then what benefit of REST vs HTTP/XML/RPC makes
it worth it? If we were not supporting SOAP, then I would be all for using
pure REST... (especially if there was a mature toolkit like axis to do a lot
of the work for me :) ).

Kind regards,

Archive powered by MHonArc 2.6.16.

Top of Page