Question

我以前开发了几个REST API，目前正在为我们公司的内部软件解决方案构建一个新的API。我选择了MEAN堆栈来构建这个和Mongoose来管理模式设计和数据层验证。良好的设计，耐用性和可扩展性是我的首选。

API将由我们的内部Angular应用程序，Android应用程序使用，谁知道还有什么，它可能有一天会被我们的PHP网站消费，或者未来我们可能会为其他企业提供平台。< / p>

我目前正在权衡两种设计：

通用：根据身份验证提供对API使用者的受限CRUD访问权限的访问权限，为复杂请求提供自定义端点。有点像Parse。
受限制：过去曾使用过此功能。 API使用者提出了一个要求，然后服务器以端点的形式实现该要求。

通用设计

API使用者可以灵活地根据前端要求制作查询，同时将非常复杂的编译移动到自定义端点中。适当的全局限制（例如：最多可以返回100条记录），每个经过身份验证的系统用户类型都可以限制模式和记录级访问。

'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);
    };

创建调用的示例响应：

{
   "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);
            });

受限制的设计

获取客户端要求并提供端点。可能看起来像这样：

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()

为了防止这个问题横向发展，我希望具体而且只是坚持每种方法的利弊。

我对通用设计的看法是，它没有与服务器紧密耦合，因此我们可以构建大量功能而无需反复编码端点。如果我在4个API消费者中有相同的查询，我需要更改每个查询，如果我决定进行更改。对于受限制的设计，反之亦然。

你们可以指出更多我可能会失踪，利弊，我应该注意的事项吗？是否存在安全问题或主要设计缺陷，我可能会过度关注。

谢谢！

Answer 1

有很多优点和缺点：

通用API的优点：

它的一般用途，旨在提供对客户可以执行的所有法律功能的访问。
客户可能会使用通用API来解决他们未来甚至不知道他们需要的问题。
随着客户需求的发展，新API功能的请求可能会少得多，因为已经提供了一般访问权。

通用API的缺点：

可能需要更多的代码工作，而且很可能需要更多的测试工作。
安全或访问控制问题可能更复杂。
非预期客户滥用的可能性更高。
客户可能需要＆＃34;构建＆＃34;通过拼凑几个API调用来获取他们想要的特定功能，从而在API顶部创建自己的层。
API可能无法提供与专门针对给定客户端需求规范而设计的端点一样高效的解决方案（换句话说，客户端可能必须使用多个API请求或者可能需要获取并查看比最佳数据更多的数据。

限制API的利弊几乎与这些相反。

一个中间立场是让客户提交他们需要访问的功能的详细规范，然后设计通用API，但最初只实现解决客户当前问题所需的部分。

这为您提供了一个通用设计，使您能够以合理，有计划的方式为将来扩展对其他区域的访问做好准备。但是，您现在没有实现或不得不测试客户真正需要的更多（这通常是商业愿望）。并且，您可以100％确定您的通用实现子集满足客户当前的需求，因为您可以根据他们的需求规范对其进行测试。

一直到通用API而没有客户列表他们的特定和当前需求冒着意外地不覆盖客户需要的一切的风险。并且，它可能花费时间来实施和测试许多当前不需要的东西。

一直到限制API，通过每个特定的客户端规范请求排列API调用，这使得很难有一个全面深思熟虑的API设计（因为从一开始就没有设计过，你最终会得到大杂烩客户要求）。

据推测，你可以看出这两种极端都不太理想。

深入了解两种REST API设计的可行性

1 个答案:

通用API的优点：

通用API的缺点：