> Is it any surprise that this leads to the exposure of internal
> implementation details?
I think I know what you mean, but also believe that conclusion is a
little vague/unsupported. In REST we are essentially doing resource
oriented development, so of course we are going to publicly leak *some
knowledge* at the service domain level (it's the same property that
allows us humans to find an URI meaningful/logic/pretty and machines
to find them).
But I disagree that we're always exposing internal implementation
detail, that's entirely up to the developer if he happens to have
direct mappings (when you see it, it's usually a canonical path).
> Basically, using REST
> is similar to telling Java developers to stop using methods and instead,
> call setters on objects.
Interesting formulation, on the other hand, haven't we been taught for
years now how Pizza.create("Chicago") is better than new
Pizza("Chicago"). The former would be similar to issuing a HTTP PUT
at /Pizza/?name=Chicago... which would result in a forward to /Pizza/
Chicago/.
In any event, I don't see the problem has to do with REST
specifically. Are we leaking any less detail by going back to
overloading POST for everything as giant RPC endpoints?
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
