简体繁体 English

将ASP.net Web API用作服务层是否合适？

[英]Is it good to use ASP.net Web API as a Service Layer?

原文 2013-09-27 07:54:52 9 1 asp.net/ architecture/ asp.net-web-api

Myself and my architect are designing the architecture for one of our products and he suggested to go with Web Api as a Service Layer (because it's a light weight component). 我和我的架构师正在为我们的某个产品设计架构，他建议使用Web Api作为服务层（因为它是一个轻量级组件）。

Straight away I'm thinking how it can be used for non-http based clients and also for external clients. 我正在考虑如何将它用于非基于http的客户端以及外部客户端。 How can we provide the proxy information about our API (in case the API is having a complex type as parameter)? 我们如何提供有关API的代理信息（如果API具有复杂类型作为参数）？

Please advice whether we can use Web API as Service Layer? 请告知我们是否可以使用Web API作为服务层？

1 个解决方案

Straight away I'm thinking how it can be used for non-http based clients 我正在考虑如何将它用于非基于http的客户端

Well, it can't. 好吧，它不能。 The Web API works only on top of the HTTP protocol. Web API仅适用于HTTP协议。 If you need to use some other transport protocols such as UDP you might consider WCF instead. 如果您需要使用其他传输协议（如UDP），则可以考虑使用WCF。

How can we provide the proxy information about our API 我们如何提供有关API的代理信息

RESTful services do not have the notion of proxy information. RESTful服务没有代理信息的概念。 They should be documented well for non .NET clients. 对于非.NET客户端，应该很好地记录它们。 For .NET clients you could share the contracts (Request/Response Dto) between your server and client application. 对于.NET客户端，您可以在服务器和客户端应用程序之间共享合同（请求/响应Dto）。 The client application could then reuse those Dtos which may act as what you call proxy and which is something that exists in the SOAP world but not in the REST world. 然后，客户端应用程序可以重用那些可以充当您所谓的代理的 Dtos，这些东西存在于SOAP世界中但不存在于REST世界中。