[
Lists Home |
Date Index |
Thread Index
]
On Wed, 30 Mar 2005 18:01:47 -0500, Mark Baker <distobj@acm.org> wrote:
> assuming the data is identical in each case, what's
> easiest to integrate? Ten services with ten interfaces, or ten services
> with one interface?
>
> O(N) beats O(NlogN) every day of the week,
We've argued about this literallly for years now, and I just don't
accept the premise that those 10 RESTful services have a single
interface. The real complexity of one approach or the other depends on
all sorts of specific factors, not "O(N) beats O(NlogN) every day of
the week"
Let's consider a contrived example :
The "identical data" is an order document, "order" as in a document
describing a set of goods or services to be purchased. The various
services might be to submit an order, verify that an order was
submitted, check the status of an order, determine when an order can
be fufilled, process the order to cause it to be fufilled, cancel and
order, and so on. So, somehow or other these different operations
need to be part of the interface. If I understand REST theory, one
would have different URIs for these different services/operations and
would GET/PUT/POST/DELETE order documents to the appropriate URI. In
a SOAP interface, one could have different endpoints for each, I
suppose, but most people would probably have a single endpoint and
have each request specify some sort of an operation code to determine
which service to request. How is this more complex than having
distinct URIs to determine which service to request? You can pay the
complexity tax with nouns (URIs) or you can pay it with verbs
(operations/service identifiers), but you have to pay it.
I maintain that there is no deep architectural principle here --
either approach exposes essentially the same order of complexity from
the service provider to the service consumer.
|
