Grouper Developers Forum

[Chris Hyzer <>]

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

http://en.wikipedia.org/wiki/REST

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,
Chris