REST API设计：如何分解API对象以使其更具可扩展性和可靠性API

我们拥有用于移动电话的电子商务网站。我们正在建立宁静的API，POST，PUT，DELETE，UPDATE手机。REST API设计：如何分解API对象以使其更具可扩展性和可靠性API

每款手机都具有以下基本功能： - 价格，制造商，制造年份，颜色，折扣。

与此同时，大多数手机也会有图像。

此外其中几个有制造商保修。可以说他们中的50％。

而且很少有手机可以提供融资选择，例如我们已经与某些银行合作以便为这些贷款提供贷款。几乎80％将有这个设施。

我们决定设计API此两种方法：

方法1.所有这些在同一个JSON对象。只有一个API如：

{ 
    "basicInfo": { 
     "price": "", 
     "mfgYear": "", 
     "manufacturer": "" 
    ... 
    }, 
    "images":{...}, 
    "warranty":{...},  
    "finance":{...}  
    }

方法2.将所有这些JSON对象分开。例如：

First Api for "basicInfo". 
    Second Api for "images". 
    Third Api for "warranty". 
    Fourth Api for "finance"

我能想出每个几利弊：

APPROACH1：优点：我们相聚在服务器上的所有库存信息。这意味着更少的API命中，更少的服务器负载。此外，将来如果我们实施一些队列处理以将这些股票信息保存到数据库中，则在将股票插入数据库之前不会发布图像/保修/财务的情况，因为我们将所有信息放在一起。因此，我们首先将库存插入数据库，然后将记录插入到具有外键关系的其他表中。 缺点：此API /资源有多重责任。它会变得越来越大，将来可能会在这个API中有太多的领域。此外，这看起来像违反单一责任原则给我。

APPROACH2：优点：这看起来有点清洁和有组织。看起来每个API都有自己的职责定义。看起来可以扩展到我。如果在一个API中进行更改，则不太可能影响其他API。 缺点：服务器上的API点击次数更多。在股票发布前发布股票依赖资源的可能性更大。例如，我们可能在插入股票之前出队图像。

方法3。给出这两个选项。允许使用基本信息发送其他信息的示例以及为这些资源创建单独的API。

哪种方法最好，即更安宁，可扩展，性能更好？

来源

2017-02-20 maverick

只给出你提供的信息，这里是我设计这个系统的过程。拥有单独的手机终端，担保和融资信息。积极缓存保证，因为这些很少会改变。在手机的JSON表示中包含保修和融资信息的链接。 /phones/{phoneId}端点支持名为“expand”的查询参数。如果服务器看到expand=warranty,expand=financing或expand=warranty, financing，则除了提供链接之外，还将相关的JSON嵌入到电话资源中。现在客户可以选择他们需要的信息并获得它。

对于图像，如果可能的话使用CDN照顾他们的，只是包括一个链接。如果您需要在您的API中管理它们，那么我会将它们视为上述保修和融资。确保它们非常积极地缓存，因为手机看起来不会经常变化。如果您需要更改图像，请使用新文件名。

这种方法的一个例子可以在规格为JSON API，其中相关的属性被称为“包括”可以看出。 JSON API对你来说可能太重了，但它有一些好点子，值得浏览规格。

最后，注意，这类开放式的问题是比较合适https://softwareengineering.stackexchange.com/。堆栈溢出用于提供正确答案的问题。

来源

2017-02-20 21:46:08

那么post呢？我想你已经回答了。帖子应该分开还是我们应该只给一个Api？ – maverick

@sahil你真的希望客户通过'POST'来更新'/ phones'的保修吗？这对我来说似乎是个坏主意。我会想象，多个手机将分享保修。同样，如果供应商和产品线相同，则对于多个分立电话来说，融资信息可能是相同的。要求客户更新这些东西以分开进行。 –

每部手机都会有不同的EMI金额，任期和将提供此服务和其他几个领域的银行名称。现在，我们应该使财务信息的一部分，电话api发布或保持它作为单独的资源？ – maverick

我无亲用JSON，但据我所知它可以堆叠这些对象，所以你可以有一个层次的（全）推动的插入/更新，也完成（或预期不完整）GET-调用。

这样你就不必炸毁每推/拉动作，并且仍然灵活，当谈到扩展。您也可以 - 或者很可能想 - 调用专门的例程来插入/更新每个子对象，以便您可以提供并使用这些作为REST API的一部分。

对于拉动，您可以将缺失的节点标记为undecided，或者已经针对数据库进行检查并标记为unloaded或not available。

请记住，如果你对所有子对象提供的API（APP.1或3）它总是会到调用者拥有这些电话sorted-尤其是当它涉及到的缺失通常按相反的顺序完成。

如果您决定使用复杂的API（1或3），您可以 - 但是 - 仍然可以使用队列和超时。因此，您可以将请求（主要是写入）存储在队列中，并且在短暂超时之后，将数据转发到插入/更新（/删除）例程之前，请检查队列。

来源

2017-02-20 21:49:06 RuDevel

方法1：优点：[...]我们将首先将库存插入到数据库中，然后将记录插入到具有外键关系的其他表中。

如果你想建立一个强大的API，比去，因为它会告诉你安全地进行交易的方式。

缺点：此API /资源具有多重责任。它会变得越来越大，将来可能会在这个API中有太多的领域。

您可以减少此检索required fields only的负面影响。

来源

2017-02-20 22:09:01

我们可以通过在方法2中插入股票之前不允许张贴图像/财务信息来实现安全交易。你有没有其他理由支持方法1？ – maverick

这是否意味着API消费者的业务逻辑[迁移]（https://www.thoughtworks.com/insights/blog/rest-api-design-resource-modeling）？ –

是的。我们也可以做到这一点。 – maverick

REST API设计：如何分解API对象以使其更具可扩展性和可靠性API

回答

相关问题