Spring Data REST
  1. Spring Data REST
  2. DATAREST-56

RepositoryRestHandlerMapping shouldn't register itself with highest precedence

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 1.0.0 GA
    • Fix Version/s: 1.1.0.M1
    • Component/s: None
    • Labels:
      None

      Description

      RepositoryRestHandlerMapping currently registers itself using Ordered.HIGHEST_PRECEDENCE which makes it impossible for other controllers to blend into the URI space of the exposed resource. E.g. we have Order instances exposed via /orders and a manually implemented controller would like to expose a payment resource for each order by handling /orders/1/payment. Even if the controller registers for this pattern, it does not get selected for request invocations as the RepositoryRestHandlerMapping already answers the lookupHandlerMethod(…) call. This is not consistent to the way mapping resolution works with plain Spring MVC where a more concrete (e.g. a dedicated /orders/

      {id}/payment) trumps a more general mapping (e.g. /{repository}/{id}

      /property).

      In any case, the RepositoryRestHandlerMapping should check whether the third segment of the URI actually really maps to a linkable property or else abstain from handling it.

        Activity

        Hide
        Jon Brisbin added a comment -

        Are you wanting a solution for this specific situation, or are you wanting a solution that fits all levels of URIs down to linked properties in a short-circuit fashion?

        e.g. it would be relatively easy to inspect the entity metadata for property names if I split out the URL based on '/'. But I'd have to put checking in to make sure that I'm dealing with a URL with only three segments (and what about the situation where we fix the prefixing so a user can override the prefix and put extra path information in front of "/

        {repository}

        "?

        I guess it just matter how much work the HandlerMapping should do that will be repeated once the handler method is actually invoked (or maybe that stuff could be cached in the Request?).

        Show
        Jon Brisbin added a comment - Are you wanting a solution for this specific situation, or are you wanting a solution that fits all levels of URIs down to linked properties in a short-circuit fashion? e.g. it would be relatively easy to inspect the entity metadata for property names if I split out the URL based on '/'. But I'd have to put checking in to make sure that I'm dealing with a URL with only three segments (and what about the situation where we fix the prefixing so a user can override the prefix and put extra path information in front of "/ {repository} "? I guess it just matter how much work the HandlerMapping should do that will be repeated once the handler method is actually invoked (or maybe that stuff could be cached in the Request?).
        Hide
        Oliver Gierke added a comment -

        I've just changed the custom HandlerMapping implementation to invoke the constructor with Ordered.LOWEST_PRECENDENCE and everything works as expected now. I think it makes sense to allow user code "interfering" with the URI space of the REST exporter by defining more concrete mappings. This is nice mechanism to let the user gain full control over resources managed by the default exporter otherwise. E.g. I want to handle delete requests to my order resource manually, so I simply declare a controller method mapped to /orders/

        {id}

        with RequestMethod.DELETE and this method will be preferred over the standard handling.

        If that is in place, I don't think we need to be overly detailed in analyzing the URI more than we do right now. At least for now this should be fine.

        Show
        Oliver Gierke added a comment - I've just changed the custom HandlerMapping implementation to invoke the constructor with Ordered.LOWEST_PRECENDENCE and everything works as expected now. I think it makes sense to allow user code "interfering" with the URI space of the REST exporter by defining more concrete mappings. This is nice mechanism to let the user gain full control over resources managed by the default exporter otherwise. E.g. I want to handle delete requests to my order resource manually, so I simply declare a controller method mapped to /orders/ {id} with RequestMethod.DELETE and this method will be preferred over the standard handling. If that is in place, I don't think we need to be overly detailed in analyzing the URI more than we do right now. At least for now this should be fine.
        Hide
        Oliver Gierke added a comment -
        Show
        Oliver Gierke added a comment - Submitted pull request: https://github.com/SpringSource/spring-data-rest/pull/49
        Hide
        Jon Brisbin added a comment -

        Fixed in latest snapshots.

        Show
        Jon Brisbin added a comment - Fixed in latest snapshots.

          People

          • Assignee:
            Jon Brisbin
            Reporter:
            Oliver Gierke
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: