使用两个端点：一个用于已弃用的api，另一个用于新的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
    ...
}

在此方法中，可以使用任何参数名称。对于那些需要旧名字的人，你可以保留旧名字。
关于终结点的数量：我指的是两个终结点：一个是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;
    ...
}

保存这样的代码可能相当复杂。例如，如果某些参数是必需的，那么在一个端点中实现它会很复杂并且容易出错，但是如果您有两个不同的端点，则实现起来非常简单。我劝你不要用这种方法。
我的建议是：为那些想使用不推荐的api的人提供一个单独的端点。他们不必更改代码，只需更改配置参数以指向一个已弃用api的端点。如果他们想继续使用不推荐的api，这是一个正常的价格。