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