Eric writes, in the context of discussing the coupling of client and server via interface (getStockQuote) semantics;

No, it doesn’t need to understand the semantics. It’s enough to define the data and associate it with a service name.
Trackback

no comment until now

  1. Hi Mark,

    For some reason I didn’t notice this till today. I do not mind being called a “REST-head” despite my involvement in Web services. I actually think REST is very close to the way in which people would get the most benefit from Web services. For example, I have never said that Web services are good for RPC oriented interactions (yes I know you can use Web services this way but I don’t think it’s the best use of the technology). The main difference seems to be over the use of custom interfaces, or perhaps mainly the question of whether or not an interface should include an “action” or “method” name – some kind of logical name or environment variable – that can be used to connect the service to an implementation environment. I think this bridge needs to be part of the formal definition of the technology.

    Regards,

    Eric

  2. Ego surfing again, eh Eric? 8-)

    I think we’ve had this discussion before, probably in the Web Services Architecture WG. I remember you talking about “bridging” and “connecting service to implementation” there. But for the benefit of anybody who happens by these comments, I’ll quickly respond …

    I don’t think a uniform interface prevents this connection that you require from being made, it just changes how it’s done.

    Consider a single chunk of code that sources two different stock quote feeds, one for Google and one for Iona. Without interface constraints you could connect this implementation to an interface (or more than one if you like) in many ways, including having a single interface with two operations, getGoogleStockQuote and getIonaStockQuote.

    But with the uniform interface constraint that approach won’t work because you’ve only got GET to request data, and obviously a single interface won’t be able to distinguish between a GET for a Google quote vs GET for a Iona quote. That’s why REST requires in this case, that there be two interfaces “connected” to that one implementation. i.e. one GET interface for the “Google stock quote” service, and one GET interface for the “Iona stock quote” service. It also means that each data source becomes a first class resource and therefore that each gets its own URI.

Add your comment now