Устаревать параметры пейджинга - PullRequest
Новая
       5

Устаревать параметры пейджинга

1 голос
/ 25 января 2020

Недавно у меня был запрос на переименование параметров подкачки пружины REST "page" и "size" в "pageIndex" и "pageSize". Мой контроллер принимает объект Pageable в качестве параметра. Тем не менее, я понимаю, что могу переименовать эти параметры, установив следующие свойства следующим образом: 

spring.data.rest.page-param-name=pageIndex
spring.data.rest.limit-param-name=pageSize

Однако, поскольку API, над которым я работаю, активно используется другими разработчиками, мне нужно не рекомендуется удалять вместо того, чтобы удалять параметры "page" и "size" (сохраняя при этом api относительно их значений), одновременно поддерживая новые имена параметров с возможностью постраничного вывода. Я просмотрел различную документацию и статьи, и после дня поиска мне все еще не ясно, как решить эту задачу.

Мой метод контроллера выглядит примерно так: 

@ApiPageable
@RequestMapping(produces = MediaType.APPLICATION_JSON_UTF8_VALUE, method = RequestMethod.GET)
public Page<MyBean> getBeans(@RequestParam(required = false) final String blah,
                               final Pageable pageable) {

    return someService.doSomething(blahStr, pageable); 
}

Заранее спасибо, и если бы в течение моего дня поиска я мог пропустить ключевой документ, который искал, пожалуйста, укажите мне его направление и примите мои извинения.

РЕДАКТИРОВАТЬ: Чтобы прояснить этот вопрос немного ... Переименование не связано с изменением URL. На самом деле URL должен оставаться идентичным. Вместо этого переименовывается набор параметров подкачки URL . Для ясности, если конечная точка, к которой относится этот вопрос, выглядит следующим образом и исключает набор общих параметров подкачки, обычно используемых в некоторой перестановке или комбинации (но не ограничиваясь ими) следующего: 

/beans
/beans?page=2
/beans?size=5
/beans?page=2&size=5
/beans?sort=created,ASC&page=4&size=6

... затем создание второй конечной точки с тем же URL-адресом (но со всеми параметрами с обязательным помеченным как false) дает мне неоднозначное отображение, когда я пытаюсь запустить API. Таким образом, если не существует удобного способа различения guish этих конечных точек (как конечной точки, использующей устаревшие параметры, так и новой, использующей новые параметры), для этого решения потребуется более двух конечных точек, ... или, предпочтительно, существует ловкий способ «серебряной пули» для решения этой проблемы .

1 Ответ

1 голос
/ 25 января 2020

Используйте две конечные точки: одну с устаревшим API и одну для новой. В устаревшем API преобразуйте устаревшие параметры в новые, вызовите свою внутреннюю службу, преобразуйте ответ в устаревший ответ.

Позже, после того, как все клиенты мигрировали в новый API, или после предварительно определенного периода миграции, вы можете решите удалить устаревшую конечную точку.

Обновление

Для клиентов, которые не могут (или еще не хотят) использовать измененный API, укажите конечную точку, которая реализует старый API. Этот метод может выглядеть следующим образом: 

@GetMapping(path = "/oldapi/...")
public Page<MyBean> getBeans(
    @RequestParam(required = false) final String blah,
    @RequestParam(value = "pageSize", required = false) Integer pageSize,
    @RequestParam(value = "pageNum", required = false) Integer pageNum,
    @RequestParam(value = "sort", required = false)
) {
    // Create Pageable object from request parameters
    ...
    // Call service or repository with this pageable
    ...
}

В этом методе вы можете использовать любые имена параметров. Для тех, кому нужны старые имена, вы можете оставить старые имена.

Для количества конечных точек: я имел в виду ровно 2 конечных точки: одну, чьи имена API остаются неизменными, а другую, которая изменяется (вы написали У меня недавно был запрос на переименование ... )

Обновление 2

Хороший способ поддержки 2 версии API - использовать 2 конечные точки . Если вы хотите предоставить 2 API через одну конечную точку, это может привести к ошибкам. В простых случаях это возможно. Например, вы определяете свой метод следующим образом: 

@GetMapping(path = "/oldapi/...")
public Page<MyBean> getBeans(
    @RequestParam(value = "size", required = false) Integer size,
    @RequestParam(value = "pageSize", required = false) Integer pageSize,
    @RequestParam(value = "page", required = false) Integer page,
    @RequestParam(value = "pageIndex", required = false) Integer pageIndex,
    ...
) {
    Integer pSize = pageSize != null ? pageSize : size;
    Integer pIndex = pageIndex != null ? pageIndex : page;
    ...
}

Хранение такого кода может быть довольно сложным. Например, если некоторые параметры являются обязательными, сложно и ошибочно реализовать их в одной конечной точке, но очень легко, если у вас есть 2 разные конечные точки. Я отговариваю вас использовать такой подход.

Мое предложение: Для тех, кто хочет использовать устаревший API, предоставьте отдельную конечную точку. Им не нужно менять свой код, нужно только изменить параметр конфигурации, чтобы он указывал на конечную точку с устаревшим API. Это нормальная цена для них, если они все еще хотят использовать устаревший API.

...