我有一个带有Web API接口的Windows服务。我使用此服务将数据从一个系统上传到另一个系统。
我的问题是另一个系统，即我必须上传数据的系统，是一个Web API服务，我不确定是否一个好主意做一个web api调用，在内部进行另一个web api调用。也许我可以在不使用Windows服务的情况下将数据直接上传到该Web API系统。
此Windows服务存在，因为包含要上载数据的程序不需要知道我将上传数据的位置。在Windows服务上，我可以将Web api更改为存储过程以按配置上载数据。我正在尝试创建一个解耦系统。注意：存储过程会将数据上载到数据库在Web API系统中使用的其他数据库。
但是，如果Windows服务具有与具有API接口的其他系统相同的API接口，则可以创建解耦系统。在我上传的程序中，我将URL从Windows服务更改为Web API系统。
您对此设计有何看法？当我可以直接调用它时，从web api调用web api是一个好主意吗？
答案 0 :(得分：0)
这取决于您的目的，通常在以下情况下使用来自web api的wep api：
- 您需要避免跨域
- 您需要自适应某些界面但不想更改原始界面
- 您希望在执行原始API之前再做一些操作
在你的情况下，可以这样做。
答案 1 :(得分：0)
您对此设计有何看法？当我可以直接调用它时，从web api调用web api是一个好主意吗？
它被称为服务代理，网关或外观。不确定原始名称是什么，谁声称它，但使用它没有任何问题。实际上，将目标服务隐藏在代理后面是很常见的。如果需要，可以在以后添加其他功能。例如，您可以在不影响现有使用者的情况下引入重试逻辑，缓存，负载平衡，新服务调用，自定义错误处理甚至新技术。基本上，这是维护服务版本控制的正确方法。如果您公开了/api/v1/upload并决定引入/api/v2/upload其他字段A-Z，则可以隐藏v1后面的v2并发送默认值而不是A-Z。我不是说这是好设计，但我相信你已经看过了。在同步API后面隐藏异步API是另一个例子，虽然不是很好。