dev@jsr311.java.net

Re: Matching algorithm for resources

From: Jan Algermissen <algermissen1971_at_mac.com>
Date: Tue, 24 Apr 2007 17:53:09 +0200

Paul,

yes, all good and valids points. I have been thinking about the
various handler classes as being less strictly related I guess.

Question:

How does the dispatching work anyhow? Since the URI -> class mapping
is only prsent inside the source code, how does the container access
the mapping for dispatching?

Is your idea that, after pluging the classes in, the root class(es)
paths' are added to the containers configuration? Or does the initial
request handler iterate over the available handler classes o check
for a match?

-------

This reminds me: does the API so far include a standard way to access
container configuration (for the handler classes to access
configuration time parameters)?


Talk to you in about an hour...


Thanks,
Jan

On 24.04.2007, at 14:06, Paul Sandoz wrote:

> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>