On Jul 8, 2008, at 9:25 AM, Manger, James H wrote:
>
> > The issue though is that we are then diverging from the likely
> path of the URI template specification which is what gives me pause
> on the whole regex idea.
>
> Divergence for the URI path matching syntax should not be an issue
> as the URI template draft spec is adamant that its templates “were
> not designed for that use case [URI path matching], nor are they
> appropriate for that purpose” [§1.3 Applicability].
>
> Avoiding divergence for the UriBuilder syntax would be nice.
>
>
> JAX-RS’s hassle is that it reuses the same @Path values for both
> tasks.
>
> This reuse will always fall foul of Postel’s Law: “be liberal in
> what you accept, and conservative in what you send”.
> @Path needs to be liberal as it is used to accept URIs from other
> parties.
> UriBuilder needs to be conservative as it builds URIs to send to
> other parties (eg as HTTP requests).
>
I don't want two different path template formats in the API, one for
matching and one for building. IMO, that would be too confusing and
would prevent the kind of DRY usage (easily building a URI for a
resource) that makes the API easy to use. Using hypermedia as the
engine of state means that often the URIs used within an application
will be produced by components of the application anyway.
The more I think about it, the more I favor the lowest common
denominator subset approach we have now.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.