在 POST 处理程序中执行 GET 请求和检查是否正确？
Is it correct performing GET requests and checks inside a POST handler?
我正在设计机票预订API。现在订票解析为 POST /users/{id}/tickets 但每个 /events/{id} 都有最大可用票数。如何正确设计支票？
我想出了两个办法：
1) 在 /events/{id} 中有一个 availibleTickets: 字段，每次我 POST 一张新票时都会检查并可能更新。
2) 将 maxTickets: 字段放入 /events/{id} 并检查 GET /events/{id}/tickets 数组的长度，将其与 maxTickets
进行比较
无论如何，我必须在 POST 处理程序中执行 GET 请求，但它对我来说不合适，你有什么建议吗？
在 post 方法 (server-side) 中，您必须在预订活动之前检查门票是否可用。
如果需要，您可以创建特定路线以了解有多少票可用。客户可以在预订活动之前调用它。或者在 get /events/{id}
中给出 availibleTickets
假设10个客户同时试图购买最后一张票，如果安全性不在post方法中，您将预订9张假想票
您将如何为网页设计票务系统？您应用于网页的相同步骤也适用于 REST，因为它只是 Web 上使用的相同交互流程的概括。
通常，您可以在 Web 上看到 link 可以订购门票的活动。在此页面上，您可以使用 link 来订购该特定节目的门票。根据您使用的系统，如果有特定的座位顺序，您可能会看到以按钮或图像形式出现的活动场地布局，其中可用座位标记为绿色，而已预订的座位标记为红色或其他颜色你使用的方案。单击一个座位将在服务器上触发一些预订逻辑，returns 几乎与以前相同的页面，但这次座位标记为橙色以表示预订。接下来，您单击该座位旁边的可用座位以预订更多座位。这个故事一直持续到您有足够的座位标记为保留或没有可用的座位，并且您没有选择取消预订、继续订购步骤或取消保留您事先标记为保留的座位。对您的选择感到满意后，您会找到一个订单或提交按钮或 link，您可以在其中将您的预订变为预订。这可能涉及一些进一步的步骤，例如输入您的联系人 and/or 帐单信息。尽管原则上这就是我为 Web 设计此类系统的方式。
如您所见，这变成了某种状态机，服务器会告诉您在当前进程状态下可用的所有选项。这正是 Asbjørn Ulsberg 在谈到 affordance and state machines 时提到的。从场地的蓝图和该蓝图上的各个座位（实际上是您可能单击的按钮或图像）来看，您知道这些小部件的用途，并且您不知何故知道当您单击其中一个座位时会发生什么。这就是 affordance 的意义所在。看到它你就知道你能用它做什么。
应该采用上面概述的交互概念并将其转换为 REST。作为客户端，您不需要知道 URI 的结构，您只需要知道有哪些座位可用以及当您单击某些 link 时会发生什么。这通常在 REST 中通过 link 关系名称完成，这些关系名称为提到的 link 客户端刚刚获取的资源的当前状态提供了一些语义上下文。这样的 link-relations 可能看起来像 a-priori 客户端需要的知识，有点 anti-REST，因为 REST 试图将客户端与服务器解耦，以允许后者自由发展，而不会冒客户端风险中断，尽管 link-relations 应该是 standardized, or should be based on extensions, such as dublin-core or other microformats。建立标准将导致不同客户的广泛接受和支持，或者建立机制 plug-in 以后将此类知识传递给客户。这通常可以避免 so-called out-of-band 强制您查找有关如何使用该系统的手册的信息或流程。
上述方法将利用在“输入”预订时唯一创建的自己的预订资源，该资源一直保留到调用订单票据步骤。此预订资源跟踪用户到目前为止选择的预订座位。系统是否将其他用户的预留座位视为已占用是一个实现细节。可以使用 first-come 系统或更礼貌的系统来保证保留者的座位，直到一些 grace-period 已经过去并且用户没有订购它们。这给你一个很好的印象，即这些资源可能是易变的，只是某个过程的一部分。
关于是否使用GET、POST或其他HTTP方法，将您转到预订页面的网页将显示一个包含会场所有座位的表格。由于HTML只支持GET或POST，所以后者是最合适的。但在 REST 或 HTTP API 中，您可能会使用 PUT。服务器可能已经为您分配了某个唯一的“预订”link，您只需使用 PUT 即可调用。如果预订资源不存在，将为您创建，如果存在，将更新全部内容。尤其是当您处理预订和资金流时 you want to use idempotent methods such as PUT.
我希望我能给您一些想法，告诉您如何设计您的预订系统，方法是让服务器向客户端传授完成任务所需的一切知识。
我正在设计机票预订API。现在订票解析为 POST /users/{id}/tickets 但每个 /events/{id} 都有最大可用票数。如何正确设计支票？
我想出了两个办法：
1) 在 /events/{id} 中有一个 availibleTickets: 字段，每次我 POST 一张新票时都会检查并可能更新。
2) 将 maxTickets: 字段放入 /events/{id} 并检查 GET /events/{id}/tickets 数组的长度，将其与 maxTickets
无论如何，我必须在 POST 处理程序中执行 GET 请求，但它对我来说不合适，你有什么建议吗？
在 post 方法 (server-side) 中，您必须在预订活动之前检查门票是否可用。
如果需要，您可以创建特定路线以了解有多少票可用。客户可以在预订活动之前调用它。或者在 get /events/{id}
中给出 availibleTickets假设10个客户同时试图购买最后一张票，如果安全性不在post方法中，您将预订9张假想票
您将如何为网页设计票务系统？您应用于网页的相同步骤也适用于 REST，因为它只是 Web 上使用的相同交互流程的概括。
通常，您可以在 Web 上看到 link 可以订购门票的活动。在此页面上，您可以使用 link 来订购该特定节目的门票。根据您使用的系统，如果有特定的座位顺序，您可能会看到以按钮或图像形式出现的活动场地布局，其中可用座位标记为绿色，而已预订的座位标记为红色或其他颜色你使用的方案。单击一个座位将在服务器上触发一些预订逻辑，returns 几乎与以前相同的页面，但这次座位标记为橙色以表示预订。接下来，您单击该座位旁边的可用座位以预订更多座位。这个故事一直持续到您有足够的座位标记为保留或没有可用的座位，并且您没有选择取消预订、继续订购步骤或取消保留您事先标记为保留的座位。对您的选择感到满意后，您会找到一个订单或提交按钮或 link，您可以在其中将您的预订变为预订。这可能涉及一些进一步的步骤，例如输入您的联系人 and/or 帐单信息。尽管原则上这就是我为 Web 设计此类系统的方式。
如您所见，这变成了某种状态机，服务器会告诉您在当前进程状态下可用的所有选项。这正是 Asbjørn Ulsberg 在谈到 affordance and state machines 时提到的。从场地的蓝图和该蓝图上的各个座位（实际上是您可能单击的按钮或图像）来看，您知道这些小部件的用途，并且您不知何故知道当您单击其中一个座位时会发生什么。这就是 affordance 的意义所在。看到它你就知道你能用它做什么。
应该采用上面概述的交互概念并将其转换为 REST。作为客户端，您不需要知道 URI 的结构，您只需要知道有哪些座位可用以及当您单击某些 link 时会发生什么。这通常在 REST 中通过 link 关系名称完成，这些关系名称为提到的 link 客户端刚刚获取的资源的当前状态提供了一些语义上下文。这样的 link-relations 可能看起来像 a-priori 客户端需要的知识，有点 anti-REST，因为 REST 试图将客户端与服务器解耦，以允许后者自由发展，而不会冒客户端风险中断，尽管 link-relations 应该是 standardized, or should be based on extensions, such as dublin-core or other microformats。建立标准将导致不同客户的广泛接受和支持，或者建立机制 plug-in 以后将此类知识传递给客户。这通常可以避免 so-called out-of-band 强制您查找有关如何使用该系统的手册的信息或流程。
上述方法将利用在“输入”预订时唯一创建的自己的预订资源，该资源一直保留到调用订单票据步骤。此预订资源跟踪用户到目前为止选择的预订座位。系统是否将其他用户的预留座位视为已占用是一个实现细节。可以使用 first-come 系统或更礼貌的系统来保证保留者的座位，直到一些 grace-period 已经过去并且用户没有订购它们。这给你一个很好的印象，即这些资源可能是易变的，只是某个过程的一部分。
关于是否使用GET、POST或其他HTTP方法，将您转到预订页面的网页将显示一个包含会场所有座位的表格。由于HTML只支持GET或POST，所以后者是最合适的。但在 REST 或 HTTP API 中，您可能会使用 PUT。服务器可能已经为您分配了某个唯一的“预订”link，您只需使用 PUT 即可调用。如果预订资源不存在，将为您创建，如果存在，将更新全部内容。尤其是当您处理预订和资金流时 you want to use idempotent methods such as PUT.
我希望我能给您一些想法，告诉您如何设计您的预订系统，方法是让服务器向客户端传授完成任务所需的一切知识。