Jan Algermissen wrote:
> Hi Paul,
>
> maybe i am missing something, but I do not see how e.g. the
> InvoiceResource is matched on a request URI?
>
InvoicesResource refers statically to InvoiceResource using the
SubResource annotation:
@UriTemplate("/invoices")
@SubResources({InvoiceResource.class})
class InvoicesResource { ... }
@UriTemplate("{invoice_Id}")
class InvoiceResource { ... }
Thus the URI path to InvoiceResource is:
/invoices/{invoice_Id}
i.e. the coalescing of the templates.
It is presented as steps 1 and 2 in the example table. I should have put
the Java classes in the table as well as it might have made things a
little clearer.
> Something else:
>
> I think that the actual paths (e.g. /invoice) are a configuration time
> issue and that dispatching from a request URI to
> a handler class should be done by a seperate component; it should not be
> part of the handler classes' source code
> (even if it's just an annotation).
>
This was an explicit design decision. We did not want to separate out
these things and wanted to keep the object model closely related to the
URI path hierarchy. See stapler [1] for more rational.
> Suppose I hand the class files for the code below to someone else that
> really does not want the path to be '/invoices'; what then?
>
This is not supported. (But i suppose it is possible to support such
aliasing in an underlying container by mapping between URI paths.)
Is it not the case that the designer of the Web application usually
controls the URI space and the relationship between resources in that
URI space?
In your experience how common a use-case would it be that the URI
templates would require changing while still keeping the Web application
consistent for the relationships between the resources?
For the Web application there are relationships between resources that
need to be maintained: between invoices and invoice, invoice and
deliveries, invoice and payments etc. Thus when considered as a whole
thing needs to interconnect. We chose a design where this
interconnection is part of the resource POJOs themselves so:
- the relationships between POJOs are not separated out into
two different places, there is only one place;
- related application logic need not be duplicated and/or distributed;
- POJOs can be intuitively reused without having to do
any configuration in a separate location; and
- POJOs can be polymorphic. For, example an invoice could be
polymorphic and specialized without having to break the contract
between invoices and invoice or invoice and deliveries etc.
Namely we have tried to take existing and familiar Java/OO concepts so
that it is 'as natural as possible' to develop RESTful Web applications
using just plain old Java objects.
From our experience with stapler/hudson it is often the case that
application logic can be associated quite closely with a bunch of
resources. For example in Hudson there is the concept of a job that has
a list of builds so the following URI paths interrelate for job and builds:
job/my-job/ // get all the builds
job/my-job/buildTimeTrend // get a build time history as an image
job/my-job/lastBuild // get the last successful build
job/my-job/{build} // get a specific build
Having such relationships split up in my experience can increase the
number of Java classes and/or make it harder to implement and maintain
the application logic. As a further example the Hudson root resource has
at least 20 different sub-resources that interrelate in application
logic to various degrees with the super resource. IMHO as such
relationships start to grow having to maintain things in separate places
starts to become very unwieldy.
Paul.
[1]
https://stapler.dev.java.net/what-is.html
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109