在现实世界中，可以想象两个人的姓，名和出生日期相同。
但是，在中等大小的数据库中，它很可能是同一个人的副本。为防止创建重复项，我们的用户界面要求用户首先搜索此人。如果他们想要的记录存在，则用户可以选择它。如果没有，他们可以添加它。如果需要，他们可以添加具有相同名称和名称的人-但通常，他们需要现有记录。
关键是，API应该允许用户创建新记录，但理想情况下，我希望他们首先搜索。
在API情况下，我希望能够要求用户先搜索然后在必要时添加它，但是我不确定API通常如何处理这种情况。通常会做什么？
由于其余的建筑风格使用无状态请求，因此您无法真正执行此处的要求。
这就是说，您可能会想到一个引导您完成域应用程序协议的网站：您获取加了书签的URL；该页面包含一个链接，您可以点击该链接进入搜索表单；您提交带有搜索条件的表格，并返回可能的匹配项列表和链接；通过链接进入“创建新记录”表格；用户提交此表单以请求服务器创建新用户。
但是从语义上讲，最后一个请求与将“创建新记录” URL硬编码到其中的客户端生成的请求没有什么不同。
您可以通过将信息编码到其中来使该URL难以猜测。例如，在搜索过程中，您可以将关键搜索词编码到URL中，以将其传递给表单，最后传递给表单提交，这时您可以检查所提交的记录详细信息是否与先前的搜索匹配。
超媒体API的优点之一是，由于客户端未使用URI拼写的语义，因此服务器可以将信息编码到这些URI中以供以后使用。不幸的是，作为“ RESTful” API的约束，超媒体约束很难获得心智共享。当然，这种设计并不能真正保护您免受那些确实是好的猜测的客户的侵害。