大佬们都如何管理你们的多版本接口的

@不负岁月 版本v1，v2的话一般来说是针对大版本的更新。日常开发中，通常是使用入口， 也就是控制器去区分版本。也就是说，如果是 不同的、完全不同的业务逻辑的、几乎是重写的，才去重写开发另一个版本，不是每一次迭代就另起一个版本。 无论怎么做，路由版本的区分已经写的很清楚了，肯定是分开的，跟你的命名空间有关，例如：

// v1版本的UseController
namespace App\Http\Controllers\V1;
Class UseController {

}

// v2版本的UseController
namespace App\Http\Controllers\V2;
Class UseController {

}

至于数据仓库，就看你实际的需求和怎么开发的了。一般来说数据仓库是符合单一原则的，例如：

namespace App\Http\Domain\Repositories;

Class UserRepository{
...
    public function getUserById(id int) {
    ...
    }
    ...
}

其他不管什么版本调用，它都是通过id获取用户信息，也就是说可以共用。如果v2版本需要其他的例如手机号获取用户信息，那么再写一个就好了。

至于service，就如同我之前说的：

如果是组合service，例如userOrderService，现在大版本迭代，并且v1版本也有旧的应用在用，如果添加的业务会影响旧的业务，那就开发新的service。

如果是控制器调用不同的service组合成最后的返回结果，那么就更简单了，旧的有人在用，开发新的单一service去调用新的就好。

如果不嫌折腾的话，那也可以开发不同版本的service。

但是一般情况下，维护一个版本的所有东西就好，一般的不复杂的单体项目，老老实实用mvc就好了，没必要过度设计，给自己增加工作量。

这个根据你自己的需求了呀，上面也写了的：

控制器就是:
App\Http\Controllers\V1 或者 App\Http\Controllers\Api\V1

App\Http\Controllers\V2 或者 App\Http\Controllers\Api\V2

service随便定义:
App\Services或者其他

数据仓库：
App\Repositories或者其他

@WhiteDragon 都是可以的，例如：

// 用户信息数据仓库 
use  App\Models\UserInfo;  

class  UserInfoRepository{  
    public  function  getUserInfoById($id){  
        return  UserInfo::query()->find($id);
    }  
}

// 用户设置数据仓库
class  userConfigRepository{  
    public  function  getUserConfigByUserId($userId){  
        return  UserConfig::query()->where("user_id", $userId)->first();
    }  
}

/*
* 写法一：service和数据仓库一样，符合单一原则，控制器调用不同service组合成结果
*/

// service
class  UserInfoService{
    protected  $userInfoRepository;
    public  function  __construct(UserInfoRepository $userInfoRepository){  
        $this->userInfoRepository  =  $userInfoRepository;
    }  

    public  function  getUserInfoById($id){  
        return  $this->userInfoRepository->getUserInfoById($id); 
    }  
}

class  UserConfigService{
    protected  $userConfigRepository;
    public  function  __construct(UserConfigRepository $userConfigRepository){  
        $this->userConfigRepository  =  $userConfigRepository;
    }  

    public  function  getUserConfigById($userId){  
        return  $this->userConfigRepository->getUserConfigByUserId($userId);
    }  
}


// 控制器
Class UserController extends Controller {
    protected  $userRepository;
    // 如果依赖注入的项比较多的话，可以使用容器绑定app()的方式调用不同的数据仓库
    public  function  __construct(UserRepository $userRepository) {
        $this->userRepository  =  $userRepository;
    }

    public function getUserConfig(Request $request) {
        // 省略校验参数
        ...
        // 调用service
        $user = $this->userRepository->getUserConfigById($id);
        if(!$user) {
            // 不存在判断和处理
        }
        $userConfig = $this->userConfigService->getUserConfigByUserId($user->id);
        // 判断是否为空，处理异常，返回结果等操作
        ....
    }
}

/*
* 写法二：service是复合功能，控制器对应功能的service即可
*/

// service
class  UserConfigService{
    protected  $userInfoRepository;
    protected  $userConfigRepository;
    public  function  __construct(UserInfoRepository $userInfoRepository, UserConfigRepository $userConfigRepository){  
        $this->userInfoRepository  =  $userInfoRepository;
        $this->userConfigRepository  =  $userConfigRepository;
    }  

    public  function  getUserConfig($id){  
        // 省略了异常处理机制，例如可以使用try catch..throw，或者直接使用return等处理方式
        $user = $this->userInfoRepository->getUserInfoById($id); 
        // 判断是否存在
        ...
        $userConfig = $this->userConfigRepository->getUserConfigByUserId($user->id); 
        // 判断是否存在，进行数据转换等操作，最后返回...
    }  
}

// 控制器：
public function getUserConfig(Request $request) {
    $userConfig = $this->userConfigService->getUserConfigByUserId($id); 
}

上述是两种常见写法，当然，也不是绝对的，例如在用户中心中，除了用户的基本信息，还需要有用户设置信息以及其他信息，那就可能是调用一次单一的service+一次/多次复合调用，具体看业务了。

版本号个人认为放在header上面不如在uri上，header中的版本号更适合存放客户端版本信息，应用路由层面还要中间件单独解析header分发请求，接口迭代，如果文档共用，入参和响应字段维护起来麻烦，接口文档语义化分组没有路径那种看的直观。