为影响多个表的动作编写API的最佳实践是什么？
考虑以下示例用例。
您需要邀请公司作为您的联系。在这种情况下需要采取的子行动是。
- 需要通过将条目添加到公司表来创建公司。
- 需要创建一个用户帐户，使工作人员通过在用户表中创建条目来登录。
- 创建员工对象是为了确保用户可以通过在员工表中创建条目来访问公司。
- 受邀的公司与受邀公司有关，因此与友谊类似的关系是通过在 Connection表中创建条目来建立了两家公司的关系。
- 创建了一个邀请对象，以存储有关谁邀请谁加入系统的信息，以及其他信息，例如邀请时间，邀请消息等，并在邀请表中创建了输入。
- 需要发送电子邮件给用户接受邀请并通过设置密码加入。
如您所见，将在5张表中制作条目。 在单个API调用中完成所有这些操作是一个好习惯吗？ 如果没有，其他选择是什么。 如果要将其分为多个API，该如何维护数据完整性？
Consider the example use case as below.
You need to invite a Company as your connection. The sub actions that needs to happen in this situation is.
- A Company need to be created by adding an entry to the Company table.
- A User account needs to be created for the staff member to login by creating an entry in the User table.
- A Staff object is created to ensure that the User has access to the Company by creating an entry in the Staff table.
- The invited company is related to the invitee company, so a relation similar to friendship is created to connect the two companies by creating an entry in the Connection table.
- An Invitation object is created to store the information as to who invited who onto the system, with other information like invitation time, invite message etc. For this, and entry is created in the Invitation table.
- An email needs to be sent to the user to accept invitation and join by setting password.
As you can see, entries are to be made in 5 Tables.
Is it a good practice to do all this in a single API call?
If not, what are the other option.
How do I maintain data integrity if it is to be split into multiple APIs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果操作需要是原子，那么绝对最好在单个API调用中执行此操作。否则，您会承担某人不完成所有要求的任务并将资源留在潜在冲突状态的风险。
也就是说，您没有更新单个资源，因此这不适合单个Restful Resource创建调用（例如，
post /company Invitations < /code>）缝合在一起可能会导致很多混乱。如果您要执行的操作是“邀请公司”，那么一个选项是使用Google的“自定义方法”语法（
post/resource/1234：action），如 aip-136 。在这种情况下，您可以做post/companies/1234：邀请，上面写着“我想邀请公司＃1234成为我的连接”。在引擎盖下，这可能会在原子上升起（创建资源尚未存在）您已列出的所有正确的内容。
If the actions need to be atomic, then it's definitely best to do this in a single API call. Otherwise, you run the risk of someone not completing all the tasks required and leaving the resources in a potentially conflicting state.
That said, you're not updating a single resource, so this isn't a good fit for a single RESTful resource creation call (e.g.,
POST /companyInvitations) -- as all these other things being created and stitched together might lead to quite a bit of confusion.If the action you're doing is "inviting a Company", then one option is to use Google's "custom method" syntax (
POST /resources/1234:action) as defined in AIP-136. In this case, you might doPOST /companies/1234:invitewhich says "I want to invite Company #1234 to be my connection".Under the hood, this might atomically upsert (create if resources don't already exist) all the right things that you've listed out.
在接近API调用时要考虑的事情是在呼叫时发生多个事情的情况，是下游动作需要多长时间。在背景中进行处理时，离开API呼叫并不是世界上最好的主意。
您可以考虑（取决于您的用语酶）接受API请求，立即以200个状态响应，然后将请求放在内部队列中进行处理。当您的背景服务拾取请求时，它可以更新需要更新的内容，并适当地管理交易。这也适合水平缩放场景，可以部署许多“ Worker”服务来处理请求。
作为其中的一部分，您可以考虑添加另一个“状态”端点，以便提出请求以了解情况。为了避免大量的投票状态请求，您也可以作为原始API调用的一部分进行回调详细信息，然后在后台处理完成后将被调用。或者您可以做到两者！
Something to consider when approaching an API call where multiple things happen when called, is how long those downstream actions take. Leaving the api call blocked isn't the best idea in the world while things are processing in the background.
You could consider (depending on your usecase) taking in the api request, immediately responding with a 200 status, and dropping the request onto an internal queue for processing. When your background service picks up the request it can update whatever needs to be updated and manage the transactions appropriately etc. This also caters for horizontal scaling scenarios where lots of "worker" services can be deployed to process the requests.
As part of this you could consider adding another "status" endpoint where requests can be made to find out how things are going. To avoid lots of polling status requests you could also take in callback details as part of the original api call which then gets called when the background processing is complete. Or you could do both!