如果您参与了webapi的设计，物联网系统，您就知道在API中使用URL的样式存在分歧，并且您选择的样式对API的可用性和使用寿命有着深远的影响。Google Cloud的Apigee团队对API设计进行了大量的思考，包括内部设计和与客户的合作，我想与您分享我们在最新设计中使用的URL设计模式，以及为什么要使用这些模式。

当您查看著名的web API时，您会看到许多不同的URL模式。

下面是两个API URL示例关于URL风格的两种不同的思想流派：https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7https://library.com/shelves/american-文学/书籍/白鲸

第一个是一个匿名简化版的真实网址，来自一家我有支票账户的美国银行。第二个是改编自Google云平台API设计指南中的一个教学示例。你可能猜到它是一个银行账户的网址，但不多。除非你非常擅长记忆十六进制字符串，否则你很难输入这个网址大多数人都会依赖复制粘贴或点击链接来使用这个网址。如果你的十六进制技巧和我一样有限，你不能一眼就知道这两个URL是相同的还是不同的，或者很容易在一个日志文件中找到同一个URL的多个匹配项。

第二个URL要透明得多。它很容易记忆，键入和比较其他网址。它讲述了一个小故事：有一本书有一个名字，它的书架上也有一个名字。这个网址可以很容易地翻译成自然语言句子。

你应该用哪一个？乍一看，URL#2似乎更可取，物联网行业，但事实却更为微妙。

标识符的情况

如果这样的标识符具有上述缺点，即难以阅读、比较、记忆和键入，并且缺少有关其标识的实体的有用信息，那么我们为什么要使用它们？

主要原因是，即使在情况发生变化时，它们仍然有效和明确，而稳定性和确定性是至关重要的品质（蒂姆•伯纳斯•李（Tim Berners-Lee）就这一主题撰写了一篇经常被引用的文章）。如果我们不为一个银行帐户分配一个标识符，我们将来如何可靠地引用它？使用我们知道的信息来识别帐户是不可靠的，因为这些信息可能会发生更改，并且可能无法唯一地识别帐户。有关其所有者的详细信息可能会发生变化（例如，姓名、地址、婚姻状况），也可能模棱两可（出生日期和地点），或者两者兼而有之。即使我们有一个可靠的所有者标识符，帐户的所有权也会发生变化，并且通过创建帐户的时间和地点来标识帐户并不能保证唯一性。

层次名称

第二个示例中由简单名称层次结构形成的URL就是基于这个想法。这些URL与简单的数字或字母数字标识符的性质相反：它们更易于人类使用、构造和获取信息，但它们在面对变化时并不稳定。

如果你了解Linnaeus的分类法，你知道，随着时间的推移，它的元素已经被重新命名，层级结构也被广泛重组；事实上，随着DNA分析等现代技术的采用，变化的速度已经加快。更改的能力对于大多数命名方案非常重要，您应该怀疑那些假定名称不会更改的设计。根据我们的经验，重命名和重新组织名称层次结构在大多数用户场景中都是重要的或可取的，即使原始API设计者没有预料到这一点。

第二个示例URL的缺点是，如果一本书或书架更改了它的名称，引用它时会基于类似示例中的层次名称URL将中断。如果一本书是大量印刷的文学作品的副本，那么更改书名可能是不合理的，但也可能适用于你可能在图书馆找到的其他文档，重命名书架似乎完全合理。类似地，如果一本书在书架之间移动，什么叫大数据云计算，这似乎也是合理的，那么基于这个URL的引用也会被打破。基于不透明标识符的url（有时称为permalinks）本质上是稳定和可靠的，但它们对人类不是很友好。使URL人性化的方法是从对人类有意义的信息（如名称和层次结构）构建URL，在这种情况下，将发生两件不幸的事情之一：要么你必须禁止重命名实体和重新组织层次结构，要么准备好处理基于这些URL的链接中断时的后果到目前为止，我已经讨论了这个身份困境对api公开的url的影响，但是这个问题也影响了存储在数据库中以及在实现组件之间交换的身份。API公开的url通常基于API实现存储在数据库中的标识，因此影响url的设计决策通常也会影响数据库和API实现设计，反之亦然。如果在实现和API中使用层次化名称来标识实体，则断开引用的后果将更加复杂，因为很难支持重命名和重租。这意味着这个主题对于整个系统设计来说是非常重要的，淘客放单平台，而不仅仅是API设计。

两全其美