为了允许多个版本的API,我使用URL来确定版本.
我阅读了这篇文章,似乎大多数人遵循这种方法：
How to organize different versioned REST API controllers in Laravel 4?
文件夹结构：
/app
/controllers
/Api
/v1
/UserController.PHP
/v2
/UserController.PHP
在UserController.PHP文件中,我相应地设置命名空间：
namespace Api\v1;
要么
namespace Api\v2;
和路线：
Route::group(['prefix' => 'api/v1'],function () {
Route::get('user','Api\v1\UserController@index');
Route::get('user/{id}','Api\v1\UserController@show');
});
Route::group(['prefix' => 'api/v2'],'Api\v2\UserController@index');
Route::get('user/{id}','Api\v2\UserController@show');
});
URL将是简单的http://…./api/v1版本1和http://…./api/v2版本.这是直接的.
我的问题是：
如果我正在构建api的小型升级,说v1.1,如何组织我的文件夹结构？
我的想法是这样的,它应该还是罚款,因为点是文件夹的有效名称？
/app
/controllers
/Api
/v1
/UserController.PHP
/v1.1
/UserController.PHP
/v1.2
/UserController.PHP
/v2
/UserController.PHP
另外,我该怎么写命名空间？这不是这样的命名空间
namespace Api\v1.1;
有可以参考使用“点”的命名约定吗？
注意：我不想将其称为版本v2,因为这不是一个主要的升级.
这样您的API版本将与路由前缀和命名空间以及测试同步.
例
>从v1.0开始
>你做一些改变(例如git-tag v1.1),这不会给你的api带来破坏性的变化.开发人员是否需要在代码中执行其他任何操作？不,那里没有.所以你可以安全地让URI-Prefix保持在V1,这样开发人员调用你的api就不需要改变所有的代码,这就是调用你的API(因此自动受益于新的小版本).也许你只是修复了一个错误,这使得他们的代码的行为与预期的一样,或者你发布了一个新功能,它不会破坏现有的功能调用.
>您的应用增长,您发布新的重新设计的API版本,其中包含突破性更改.在这种情况下,您将发布一个新的API-URI前缀(V2).
请注意,您当然可以在内部跟踪次要版本(例如SCM),但是开发人员不需要更改所有的API通话,只是为了从您发布的那个小错误中受益.无论如何,当然,如果您通知客户更新的次要版本及其提供的修补程序或增强功能(博客,通讯,…)
让我补充一下,我不知道使用小的API-URL-prefix的RESTful API,所以我猜这是一个很常见的做法.
