我正在设计一个票务预订API。现在预订机票解析为POST /users/{id}/tickets，但每个/events/{id}都有最大可用门票。如何正确设计支票？
我想出了两种方法：
1) 在/events/{id}中有一个availibleTickets:字段，每次我POST新票证时都会检查并可能更新该字段。
2)将maxTickets:字段放入/events/{id}并检查GET /events/{id}/tickets数组的长度，将其与maxTickets进行比较
无论如何，我必须在POST处理程序中执行GET请求，但对我来说看起来不对，您有什么建议吗？
您如何设计网页的票务系统？应用于网页的步骤也适用于 REST，因为它只是 Web 上使用的相同交互流的概括。
通常，在网络上，您有一个链接，您可以看到可以订购门票的活动。在此页面上，您有一个链接来订购该特定节目的门票。根据您使用的系统，您可能会看到活动场地的布局，如果存在特定的座位顺序，其中可用座位标记为绿色，而已预订的座位标记为红色或您使用的任何配色方案，则可能会以按钮或图像的形式单击。单击座位将在服务器上触发一些预订逻辑，该逻辑返回与以前几乎相同的页面，但这次将座位标记为橙色以指示预订。接下来，单击该座位旁边的可用座位以保留更多座位。这个故事一直持续到您有足够的座位标记为预留或没有可用座位，并且您没有选择取消预订、继续订购步骤或取消预订您事先标记为预留的座位。一旦您对自己的选择感到满意，您将找到一个订单或提交按钮或链接，您可以在其中将预订转换为预订。这可能涉及一些进一步的步骤，例如输入您的联系人和/或帐单信息。虽然这原则上是我为Web设计这样一个系统的方式。
如您所见，这变成了某种状态机，服务器会告诉您在进程的当前状态下可用的所有选项。这正是Asbjørn Ulsberg在谈论可负担性和状态机时提到的。从场地的蓝图和蓝图上的相应座位，实际上是您可以点击的按钮或图像，您知道这些 widge 是干什么用的，并且您以某种方式知道当您单击其中一个座位时会发生什么。这就是可负担性的全部意义所在。通过看到它，你知道你可以用它做什么。
上面概述的交互概念应该被采用并转换为 REST。作为客户端，您不需要知道 URI 的结构，您只需要知道哪些席位可用以及单击某些链接时会发生什么。这通常在 REST 中通过链接关系名称完成，这些名称为提到的链接提供客户端刚刚获取的资源的当前状态的一些语义上下文。这种链接关系似乎是客户端需要的先验知识，这有点反REST，因为REST试图将客户端与服务器分离，以允许后者自由发展而不会冒客户端中断的风险，尽管链接关系应该是标准化的，或者应该基于扩展，例如都柏林核心或其他微格式。建立标准将导致不同客户的广泛接受和支持，或者以后将这些知识插入客户的机制。这通常避免了所谓的带外信息或流程，这些信息或流程流迫使您查找有关如何使用该系统的手册。
上述方法将利用自己的预留资源，该资源在"输入"预留时唯一创建，该资源将一直保留到调用订单单步骤。此预留资源跟踪用户到目前为止选择的预留座位。系统是否将其他用户的保留席位视为已占用是一个实现细节。可以使用先到先得的系统或更礼貌的系统，以保证保留他的座位，直到某个宽限期过去并且用户没有订购它们。这给你一个很好的印象，即这些资源可能是不稳定的，只是某个过程的一部分。
关于是否使用GET、POST或其他HTTP方法，将您发送到预订页面的网页将显示包含场地所有座位的表格。由于HTML只支持GET或POST，后者是最合适的。不过，在 REST 或 HTTP API 中，您可以使用PUT。服务器可能已经为您分配了某个唯一的"保留"链接，您可以使用PUT调用该链接。如果预留资源尚不存在，将为您创建，如果存在，则只会更新整个内容。特别是当您处理预订和资金流时，您希望使用幂等方法，例如PUT.
我希望我能给你一些关于如何设计你的预订系统的想法，让服务器教客户完成任务所需的一切。
在post 方法(服务器端)中，您必须在预订活动之前检查门票是否可用。
如果需要，您可以创建特定路线以了解有多少票可用。 客户可以在预订活动之前调用它。或者在 get/events/{id} 中给出可用的票证
想象一下，10 个客户试图同时购买最后一张票，如果安全性不在 post 方法中，您将预订 9 张虚构的票