洞悉两个REST APIdevise的可行性
过去我已经开发了几个REST API，目前正在为我们公司内部的软件解决scheme构build一个新的REST API。 我select了MEAN堆栈来构build这个和Mongoose来pipe理模式devise和数据层validation。 良好的devise，耐用性和可扩展性是我的榜单之首。
API将被我们内部的Angular应用程序，Android应用程序所使用，谁知道还有什么，有一天我们的PHP网站可能会使用API，或者将来我们可能会为其他业务提供平台。
我目前正在称重两种devise：
- 通用目的 ：根据身份validation提供对除API的受限制CRUD访问权以外的所有访问权限，为复杂请求提供自定义端点。 有点像Parse 。
- 限制 ：曾经使用过这个。 API消费者提出了一个需求，然后由服务器以端点的forms完成。
通用devise
API消费者可以灵活地根据前端需求来制作查询，而非常复杂的编译则被转移到自定义的端点上。 全局限制（例如：最多可以返回100条logging），每个经过身份validation的系统用户types可以是限制性模式和logging级访问。
'use strict'; module.exports = function (app) { // Api routing var api = require('../controllers/api.controller.js'); /** * Cental API router */ app.route('/api/create') .post(api.create); app.route('/api/read') .get(api.read); app.route('/api/update') .put(api.update); app.route('/api/remove') .delete(api.remove); app.route('/api/dashboard/:country/:date') //Complex endpoint .get(api.dashboard); }; 创build调用的示例响应：
{ "response":[ { "_id":"54f703531c3757fe23923250", "entity_id":3, "customer_id":104, "base_grand_total":15, "total_qty_ordered":1, "total_item_count":1, "customer_gender":1, "shipping_address_id":6, "quote_id":8, "increment_id":"200000089", "order_currency_code":"AED", "country_id":"AE", "status":"pending_receiving" } ], "numberAffected":1, "result":"created", "dataModel":"Orders", "errorMsg":null, "error":0 }
使用案例：使用AngularJS删除用户。
var req = { method: 'DELETE', url: '/api/remove', data: {query: {'_id': id}, dataModel: 'Users' // 'Orders', 'Products' 'Etc'}, headers: { 'Content-Type': 'application/json' } }; $http(req).success(function (res) { $scope.users.splice(rowIndex,1); console.log(res); }).error(function (res) { console.log(res); });
限制devise
获取客户需求并提供端点。 可能看起来像这样：
public function userProfileAction() public function createPostAction() public function getPostsByUserAction() public function getPostsByDistanceAction() public function getPostsByFollowedUsersAction() public function getPostsByVenueAction() public function getPostsLikedByUserAction() public function deletePostAction() public function reportPostAction() public function recommendPostAction() public function followUserAction() public function likePostAction()
为了防止这个问题横向偏离，我想要具体，只有坚持每种方法的利弊。
我所看到的针对通用devise的专业人员认为，它与服务器没有紧密耦合，所以我们可以在没有后台的情况下构build大量的function，并且一次又一次地编码端点。 可以肯定的是，如果我在4个API消费者中有相同的查询，那么如果我决定进行更改，则需要更改每个查询中的查询。 对于受限devise，反之亦然。
你们能否指出我可能会失踪，利弊，我应该注意的事情？ 是否有安全问题或主要的devise缺陷，我可能会过去看。
谢谢！
有重大的利弊：
通用API的优点：
- 这是通用目的，并意味着提供访问客户端允许执行的所有法律function。
- 客户可能会使用通用API来解决将来他们还不知道他们需要的问题。
- 随着客户需求的发展，可能会有更less的新API请求，因为已经提供了一般访问。
通用API的缺点：
- 这可能是更多的工作来编写代码，很可能有更多的工作要testing。
- 安全或访问控制问题可能更为复杂。
- 意外客户滥用的可能性更高。
- 客户可能需要通过将几个API调用拼凑在一起来获得他们想要的特定function，从而在您的API之上“build立”自己的层。
- API可能无法像专门针对特定客户端需求规范devise的端点那样有效地提供解决scheme（换句话说，客户端可能必须使用多个API请求，或者可能获取并查看比是最佳的）。
受限制的API的优点和缺点几乎与这些相反。
一个中间的基础是让客户提交他们需要访问什么function的详细规范，然后devise一个通用的API，但是只有最初实现解决客户当前问题所需的部分。
这为您提供了一个通用的devisescheme，使您能够以合理的，有计划的方式扩大对未来其他领域的访问。 但是，您现在不需要执行或不得不进行比客户真正需要更多的testing（这往往是商业需求）。 而且，您可以100％确定您的通用实施子集满足客户的当前需求，因为您可以根据其需求规格进行testing。
一路走到一个通用的API没有客户名单，他们的具体和当前的需求有意外地不覆盖客户需要的一切风险。 而且，它可能花费时间来实施和testing很多目前不需要的东西。
一直到一个受限制的API，用每个特定的客户端规范请求排队API调用，都使得很难有一个全面深思熟虑的APIdevise（因为从一开始就没有devise过，而且最后只是大量的客户端请求） 。
据推测，你可以看到，没有极端可能是理想的。