常用WebAPI参数——路由vsheader？
Commonly used Web API parameters - route vs header?
我正在寻找在几乎所有 Web API 方法之间传递通用参数的最佳方式。本例中的参数是存储库标识符，因为在登录 SPA 时可以选择使用哪个数据库来读取和写入数据 from/to。然后，此选择会存储在应用程序中，并在以后的所有 API 次调用中使用。
我正在考虑的选择是：
- 路由值 - 这意味着向所有路由添加路由参数并确保为 SPA 进行的每次调用发送该参数：
[Route("api/{repo}/{user}/{id}")]。这里的优点是它可能更明确。
- 自定义 header 值，由应用程序在每个 API 请求上盲目应用，并在需要时由 API 使用。因此，要求通过此 header。这里的优势是关注点分离 - 管理用户屏幕的 SPA 部分不需要知道它正在使用哪个 repo。
对于 API 中常用的参数，是否有任何最佳实践指南？何时应传递参数 FromUri 和 FromBody 与使用自定义 header 值的区别在哪里？
这取决于具体情况，但如果您制作的 API 每次都需要传递特定参数，那么您最好在 header 中发送此参数。 HTTP header 意味着发送关于请求上下文的额外信息，但要注意添加太多 header key-value.
通过 header 和查询字符串（通过 URL）您只能发送 key-value 对中的数据，而通过 HTTP body 您可以发送不同类型的负载（数据) 即 JSON、XML、txt、FileStream 等
根据选择发送数据的方法，数据大小有一定的限制。通过 header 您可以为每个 key-value 对传递最大 8KB 的数据，在查询字符串中您最多可以添加 2048 个字符，通过 body 我们可以发送多达 0 到 >= 2 MB 数据（大小可能因服务器而异）。
详情请参考RFC 7231
它取决于用例
如果您需要在用户之间共享链接，您肯定需要使用路径
它也看起来更透明和易于理解
如果您想为最终用户隐藏信息，我认为您需要使用 headers
如果你想在这里实现某种多租户，我也可以建议为每个存储库使用不同的子域，然后添加 midleware/filter/etc 以根据请求子域解析存储库。您可以自动创建子域（大多数流行的提供商都有 API 来执行此操作）
我正在寻找在几乎所有 Web API 方法之间传递通用参数的最佳方式。本例中的参数是存储库标识符，因为在登录 SPA 时可以选择使用哪个数据库来读取和写入数据 from/to。然后，此选择会存储在应用程序中，并在以后的所有 API 次调用中使用。
我正在考虑的选择是：
- 路由值 - 这意味着向所有路由添加路由参数并确保为 SPA 进行的每次调用发送该参数：
[Route("api/{repo}/{user}/{id}")]。这里的优点是它可能更明确。 - 自定义 header 值，由应用程序在每个 API 请求上盲目应用，并在需要时由 API 使用。因此，要求通过此 header。这里的优势是关注点分离 - 管理用户屏幕的 SPA 部分不需要知道它正在使用哪个 repo。
对于 API 中常用的参数，是否有任何最佳实践指南？何时应传递参数 FromUri 和 FromBody 与使用自定义 header 值的区别在哪里？
这取决于具体情况，但如果您制作的 API 每次都需要传递特定参数，那么您最好在 header 中发送此参数。 HTTP header 意味着发送关于请求上下文的额外信息，但要注意添加太多 header key-value.
通过 header 和查询字符串（通过 URL）您只能发送 key-value 对中的数据，而通过 HTTP body 您可以发送不同类型的负载（数据) 即 JSON、XML、txt、FileStream 等
根据选择发送数据的方法，数据大小有一定的限制。通过 header 您可以为每个 key-value 对传递最大 8KB 的数据，在查询字符串中您最多可以添加 2048 个字符，通过 body 我们可以发送多达 0 到 >= 2 MB 数据（大小可能因服务器而异）。
详情请参考RFC 7231
它取决于用例
如果您需要在用户之间共享链接，您肯定需要使用路径 它也看起来更透明和易于理解
如果您想为最终用户隐藏信息，我认为您需要使用 headers
如果你想在这里实现某种多租户，我也可以建议为每个存储库使用不同的子域，然后添加 midleware/filter/etc 以根据请求子域解析存储库。您可以自动创建子域（大多数流行的提供商都有 API 来执行此操作）