假设我们有一个RESTful网络服务，可以计算英国皇家邮政的邮资费用。
会有许多必要的输入参数： 项目重量（克，整数）， 项目长度（cm，int）， item的宽度（cm，int）， 项目类别（letter / parcel，string / enum）， 需要服务（头等/第二类/特殊交付/等，字符串/枚举）， 目的地（国内/国际/可能进一步指定后者，字符串/枚举）
这样的应用程序很容易创建为WebAPI。它可以通过URL调用，如... http://myserver.com/api/mailcharges?weight=150&length=15&width=10&category=letter&service=first&destination=domestic
然后，Web服务将对其内部表执行简单查找，并在其响应有效负载中返回邮资。
它的美妙之处在于它可以被组织内的各种应用程序（甚至在它之外！）使用。但是，这要求调用Web服务的每个应用程序都需要能够填充这些参数;整数是好的，它们只是 - 数字。但是字符串或枚举更难。输入和验证这些的逻辑需要在每个客户端应用程序中复制。如果Web服务可以提示用户输入任何未传入或传递为空值或无效值的文件，那会不会更好。事实上，如果Web服务具有允许用户输入任何或所有参数的用户界面，那就不会更好了。
我正在寻找的是网站和网络服务之间的交叉。一个Web应用程序，可以通过简单的RESTful http请求调用，弹出用户对话框，接受用户输入，当用户点击合适的按钮时，进行计算并将其答案作为JSON / XML响应返回。 / p>
有没有人对如何实现这样的架构有任何想法？我尝试从web api控制器中调用MVC操作/视图，但响应是MVC视图的html，并且直接返回到api控制器而不是呈现并POST回其用户输入。
我希望自己只是变得厚重，答案显而易见，但到目前为止我所有的实验都失败了，任何建议，无论多么遥远或过分，都会受到欢迎。
我意识到这是一个相当简单的例子，但同样的论点适用于更复杂的Web服务，其中跨多个客户端应用程序的用户输入表单，输入验证，复杂处理逻辑等的复制将更多地是问题比这个例子。
答案 0 :(得分：0)
如果Web服务可以提示用户基本上缺少服务的要点。它不再是网络服务，而是网页。
为了使内部/外部应用程序/网站能够使用您的服务，他们基本上需要了解三件事：
http://myserver.com/api/mailcharges weight，length ... 虽然1.和2.通常仅仅是API文档，但您似乎遇到了问题。 3 - 您希望以某种方式提示用户在可能的值中进行选择而不是猜测。但是您还希望用户应用程序不负责维护/验证可能的值列表。
猜猜是什么？您只需要另一个API。 :)用于描述你的论点的API。让我们专注于category领域。您的API可以使用新的URL进行扩展：http://myserver.com/api/getCategories本质上返回可用（当前由API理解）可能的类别值的列表。这可以是JSON，或逗号分隔的字符串或任何可靠的。现在，最终用户启用GUI的应用程序调用API，请求类别，并相应地创建UI - 填充ComboBox或任何具有获取值的内容。其他领域也是如此。您可以。即获得weight或length的可接受范围。
您在问题中提到的重要事项是验证：用于输入和验证在每个客户端应用程序中复制这些需求的逻辑。这在某种程度上是正确的，因为它主要取决于最终用户应用程序中使用的技术。另一方面，它非常重要，API本身就会执行验证！您永远不知道谁将使用您的API。最好先检查两次，然后永远不要。