RE: Alternate API proposition

From: Jerome Louvel <>
Date: Fri, 27 Apr 2007 07:55:12 +0200

Hi Paul,

> One way we could avoid more scary string code is to expose
> URI template
> functionality to the application (to extract template values
> from a URI,
> or to produce a URI given template values), alternatively one
> can always
> use the Java regex package for more complex patterns.

That would be useful indeed. Anyway, we need a way to dynamically generate
contextual URIs inside resources. This could very well be URI template
compliant and also allow parsing.

> > In addition, it gives some
> > deployment information to the parent container.
> >
> I am not sure what it means to provide host information for
> deployment
> in say a servlet container like Tomcat. This is the kind of
> thing that
> could change between development, testing and production
> deployment so
> baking the host/port details into the application code may be
> problematic. (Internally transforming the URI won't work when URIs of
> resources need to be embedded into representations.)

Yes, in many cases that info will not be stable. The way BlinkSale uses a
subdomain for account ID is probably uncommon. So we shouldn't probably keep
this @hostRef annotation.

Best regards,