See below
On Aug 1, 2007, at 9:58 AM, Mark Baker wrote:
"what actually is going to happen" is an implementation artifact, not
part of any interface, business, technical, or otherwise. You never
want to expose implementation details because consumers tend to forge
dependencies upon them, preventing the implementation from changing in
ways which break those expectations.
Now this one is interesting and I'm not sure I agree.
I'm not sure I agree with the idea that the uniform interface provide
the power to change so transparently. Let me mention again that the
more I look at REST the more I'm enjoying it but there are some
assumptions I don't agree with - doesn't make REST bad but I think it
overstates the case. This is one of them.
If the form/schema/whatever of what I need to send to a REST resource
changes then guess what? I need to change what I send it. I can't
assume to be blissfully unaware and go on with life. If
implementations change, there is a good chance that that might effect
me. Now if the back-end database changes or the implementation
language changes that might make no difference whatsoever (btw
something that lots of non-REST technologies provide) but there are
some changes that would effect my resource interface and just because
I'm using POST doesn't mean that I won't be inconvenienced.
But, say the REST folks, because it's not so tightly coupled it won't
break so easily, it's allows things to be much more dynamic. But
sometimes it's important that such changes are VERY visible so that
my expectations are still met. I.e. I'd like to know about a change
in implementation that will effect how I interact with you.
So we can say things like business has been doing REST based
approaches for generations i.e. I use the postal service to send a
form to some department to perform some well defined action based on
the information in the form sent over a uniform interface, the postal
service. However this is nothing more annoying or indeed potentially
costly than finding out that "the form has changed" long after you
expected the action to be performed! "Why didn't someone tell me the
form changed!" We demand. "You've cost me time and money with this
delay!" So is this dynamic transparency really true? And does it
really always have value?
So on a related note then I wonder if the old "break code violently"
saying carries here too. The idea of "breaking code violently" was
that you would write sanity checks and assertions in your code so
than in testing it would crash the code if certain rules were being
broken - that way you found out very quickly where assumptions were
wrong and expectations were broken. So does the alleged
"transparency" actually delay important information about assumptions
and expectations being changed and does this have an adverse effect?
William
