1. Java / Говнокод #17072

    +73

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    @GET
    @Path("/store")
    void getStoreSummary(@QueryParam("id") final String id, final MethodCallback<StoreSummary> callback);
    
    @GET
    @Path("/store")
    void getStoreDetails(@QueryParam("id") final String id, @QueryParam("detailed") final boolean mustBeTrue, final MethodCallback<StoreInfo> callback);

    Есть API-вызов HTTP GET, который по ?detailed=true возвращает расширенный JSON с дополнительными полями.

    И вот в RestyGWT, оказывается, по-другому никак. То есть если бы других параметров запроса не было, можно было бы просто написать

    @Path("/store?detailed=true")
    . Но он не умеет добавлять динамические параметры запроса к захардкоженным. Если попытаться - получается два вопросительных знака: [/code]/store?detailed=true?id=[id][/code].

    Запостил: someone, 06 Ноября 2014

    Комментарии (13) RSS

    • I guess there is no one to blame
      We're leaving ground
      Will things ever be the same again?

      It's the final boolean
      It's the final boolean...
      Ответить
    • а опциональных параметров не бывает?
      Ответить
      • в жабе нет, да и врядли тут это бы помогло
        Ответить
        • в джаве ладно, в рести-то почему нет?

          @QueryParam(name="detailed", defaultValue=Boolean.FALSE)
          Ответить
          • > в рести-то почему нет?
            Да есть что-то такое
            @DefaultValue("false") вроде
            Ответить
          • я так понимаю, им хотелось именно на разные контроллеры запросы отправлять, а не просто дефолтное значение выставить.
            Ответить
          • Нет там такого.

            RestyGWT берёт аннотации из JAX-RS, а там такого нет. Есть @DefaultValue, но он всё равно не поможет, потому что аннотации вешаются на параметры, а не на метод. А пропустить параметр в любом случае нельзя. Если порыться в исходниках, то увидим, что он читает @QueryParam только на параметрах метода, а не на самом методе.

            В общем, я считаю, что невозможность склейки параметров строки запроса - это баг. Запощу.
            Ответить
    • а нельзя было сделать один метод, и внутри что-то вроде
      if (request.attr("detailed").isTrue()) {
          putStoreDetails(json);
      }
      Ответить
    • Ох, эти облегчающие жизнь аннотации. Вспомнил как какое-то время назад знакомство с MultipartFile и попыткой унаследоваться от этого говна, чтобы было куда валидатор прицепить. В итогде я так это и не осилил, но оно уже и не нужно было.
      Ответить
      • Ну хороши аннотации или плохи, но другого способа связать параметр HTTP запроса с параметром метода в джаве нет. Да и привязать мета-инфу к методу тоже никак. Не указывать же название метода строкой в другом месте!

        Кстати, Spring MVC прекрасно работает на аннотациях. Ну тоесть он конечно же гуано, но все остальные фреймворки в тысячу раз хуже.
        Ответить
    • > Но он не умеет добавлять динамические параметры запроса к захардкоженным

      собственно, параметры никогда не были частью рутов. на то они и параметры, что анализируются кодом.
      Ответить
      • Это клиентский код. В серверном-то, понятное дело, анализируются.
        Ответить

    Добавить комментарий