Community
Participate
Working Groups
Build Identifier: The REST service is identified by its URL, with the expectation that all accesses of a service will be via that single URL. In fact, this is pretty much against what REST stands for, since each resource is supposed to have its own URL. For example, the twitterverse has an API to acquire a current user's messages (which has a fixed URL, like /my/tweets) - but if you want to get another user's tweets, then you supply some kind of changing URL. The Twitter page gives an example: http://api.twitter.com/1/statuses/show/1472669360.xml In this case, the 147269360 isn't part of the URL as such, but rather it's a parameter to the request. Others will have subsets of the parameters in the URL and others in additional ways (http parameters etc.). Quite a common way of dealing with this is to use some kind of psuedo parameter in the URL itself, e.g. the URI Templates proposal http://code.google.com/p/uri-templates/ In fact, if you wanted to get information about a project on Google Code, you'd do http://code.google.com/p/{project}/issues/detail?id={id} Whilst 'id' can be passed in (with the current setup), the {project} can't, since it's part of the URL and thus is assumed to be fixed as part of the call. Reproducible: Always
I'm not sure I understand the desire here. The current approach allows the use of a URL fragment/prefix (e.g. http://code.google.com), and then allows the path and file name to be associated with a specific client-side method call (by defining IRemoteCallable instances that associate and arbitrary String with the path. e.g. see the test code for the twitter service in org.eclipse.ecf.tests.remoteservice.rest.twitter.TwitterRemoteServiceTest I don't see this as terribly limiting...as typically the protocol, auth, host info (e.g. http://code.google.com) is reasonably associated with a single 'service'. So if this is insufficient could you explain the use case a little further? Also, if an alternative and/or generalization is desired, please consider providing a patch/patches.
Actually, there could be many services but there may not be provided by the same prefix. For example, there might be an "issue service" and a "wiki service" for Google code projects. Arguably having them as separate services allows e.g. adding an Hg service (or Git service) but the only common prefix is http://code.google.com/p/. It may not make sense to consider those all implementations of the same ECF service.
(In reply to comment #2) > Actually, there could be many services but there may not be provided by the > same prefix. For example, there might be an "issue service" and a "wiki > service" for Google code projects. Arguably having them as separate services > allows e.g. adding an Hg service (or Git service) but the only common prefix is > http://code.google.com/p/. It may not make sense to consider those all > implementations of the same ECF service. I agree with this...it sort of doesn't make sense to consider them all the same ECF service. So in that case, it seems like having them be separate services...each with a separate ECF container instance (i.e. one per prefix) works well for the typical use case. This does have the consequence that it's impossible to have a single, massive client-side service API that includes multiple prefixes, but this doesn't seem like a huge problem to me, as the typical use case is that the scope of the 'service' is defined by the prefix (in URL terms, the protocol, authority, host, and optionally part of the path...e.g. http://code.google.com/p/). It could also be argued that having a single prefix encourages finer-grained services...which I don't think is bad thing. And, of course, it is quite possible to have multiple ECF container instances to expose multiple services (i.e. one per prefix). OTOH, it could indeed be considered an enhancement/generalization to support more than one prefix for a given container/service. Perhaps the title of this enhancement should be changed to that effect...e.g. 'support multiple URL prefixes for REST containers'...or something to that effect if I'm not understanding.
(In reply to comment #3) > I agree with this...it sort of doesn't make sense to consider them all the same > ECF service. > > So in that case, it seems like having them be separate services...each with a > separate ECF container instance (i.e. one per prefix) works well for the > typical use case. To be honest, it doesn't always work out that way. It just works that way occasionally. There are a number of services where part of the URL is an identifier for the resource. Arguably, the ones that don't tend not to be RESTful services, but more GETS oriented. For example, Amazon's S3 service uses: http://{bucket}.s3.amazonaws.com/{object} At the moment, if you assume that there is an explicit prefix-per-service, then you end up with one service per bucket, which clearly isn't the right way to scale. > This does have the consequence that it's impossible to have a single, massive > client-side service API that includes multiple prefixes, but this doesn't seem > like a huge problem to me, as the typical use case is that the scope of the > 'service' is defined by the prefix (in URL terms, the protocol, authority, > host, and optionally part of the path...e.g. http://code.google.com/p/). No, there is no direct relation between the prefix of the URL and any service. Whether that's the case for some examples doesn't make it the typical case. > And, of course, it is quite possible to have multiple ECF container instances > to expose multiple services (i.e. one per prefix). That's not a scalable solution either. Consider a Google Code issue tracking service. Would you really want to (a) enumerate all of the Google Code projects, and (b) get a service for each one of them? What you really want is something like http://code.google.com/p/issue?project=objectiveclipse&id=13, where the project and id are parameterised. But it's arguably more RESTful to put those IDs in the URL, and not as parameters to the URL itself - and that's where the whole "prefix" assumption starts breaking down. > OTOH, it could indeed be considered an enhancement/generalization to support > more than one prefix for a given container/service. Perhaps the title of this > enhancement should be changed to that effect...e.g. 'support multiple URL > prefixes for REST containers'...or something to that effect if I'm not > understanding. I think it would make sense to refer to them as parameterised or templated URLs. What we're really saying is that there should be 1 services per back-end service: http://code.google.com/p/{project}/issues http://code.google.com/p/{project}/w regardless of how many projects there happen to be (and taking {project} to be substituted by the appropriate parameter value at call time).
(In reply to comment #4) > (In reply to comment #3) > > I agree with this...it sort of doesn't make sense to consider them all the same > > ECF service. > > > > So in that case, it seems like having them be separate services...each with a > > separate ECF container instance (i.e. one per prefix) works well for the > > typical use case. > > To be honest, it doesn't always work out that way. It just works that way > occasionally. There are a number of services where part of the URL is an > identifier for the resource. Arguably, the ones that don't tend not to be > RESTful services, but more GETS oriented. > > For example, Amazon's S3 service uses: > > http://{bucket}.s3.amazonaws.com/{object} > > At the moment, if you assume that there is an explicit prefix-per-service, then > you end up with one service per bucket, which clearly isn't the right way to > scale. > > > This does have the consequence that it's impossible to have a single, massive > > client-side service API that includes multiple prefixes, but this doesn't seem > > like a huge problem to me, as the typical use case is that the scope of the > > 'service' is defined by the prefix (in URL terms, the protocol, authority, > > host, and optionally part of the path...e.g. http://code.google.com/p/). > > No, there is no direct relation between the prefix of the URL and any service. > Whether that's the case for some examples doesn't make it the typical case. I guess I'm not (yet) convinced that the examples you are giving (e.g. the Amazon S3 service) are any more typical than the examples of a single prefix-per-service approach (which seems fairly common by my survey of rest-based services). So although I'm fine with an enhancement to generalize things for a multiple-prefix-per-service approach, I don't really agree with you yet that it's the typical use case. > > > And, of course, it is quite possible to have multiple ECF container instances > > to expose multiple services (i.e. one per prefix). > > That's not a scalable solution either. Consider a Google Code issue tracking > service. Would you really want to (a) enumerate all of the Google Code > projects, and (b) get a service for each one of them? I would personally prefer them to be separate services rather than jumbled together into one service...i.e. finer granularity. >What you really want is > something like http://code.google.com/p/issue?project=objectiveclipse&id=13, > where the project and id are parameterised. But it's arguably more RESTful to > put those IDs in the URL, and not as parameters to the URL itself - and that's > where the whole "prefix" assumption starts breaking down. Again, although admittedly this situation does exist, I wouldn't call it typical. > > > OTOH, it could indeed be considered an enhancement/generalization to support > > more than one prefix for a given container/service. Perhaps the title of this > > enhancement should be changed to that effect...e.g. 'support multiple URL > > prefixes for REST containers'...or something to that effect if I'm not > > understanding. > > I think it would make sense to refer to them as parameterised or templated > URLs. What we're really saying is that there should be 1 services per back-end > service: > > http://code.google.com/p/{project}/issues > http://code.google.com/p/{project}/w > > regardless of how many projects there happen to be (and taking {project} to be > substituted by the appropriate parameter value at call time). Ok, sounds reasonable. Please consider sketching out an API addition+impl as a contribution, and we'll attempt to get it into next version (3.4...which we haven't set the exact date yet, but I think it will be in Sept 2010 timeframe).
Resolving as wontfix due to limited resources for additional work in this area. If contributor or committer resources become available for the API additions/enhancements described/discussed in comments, then please reopen.
