开发web服务时有哪些陷阱/技巧

Always handle errors and exceptions.

问题总是会在应用程序/api中出现。无论是在开始或通过进一步发展。不要将此作为一个结束任务,并在发生错误时用有充分记录的响应消息来明确说明。

另外,如果您的服务将处理许多请求,并且对于相同的资源id(独立于用户),返回相同的资源,请确保缓存信息。这不仅是因为性能原因,而且是因为出现错误的情况。这样,您至少可以为客户机提供一些服务(可能有用,需要更明确的上下文)。

我能提供的最大和最重要的一点是保证您在WS背后的基础设施,或者至少您通过WS提供的服务是无状态的。一旦你偏离这一点,它将成为一场噩梦,你将不得不开始塞进代码,以保护你的数据不被弄脏。

另外,考虑API的深度,就像任何面向公众的API一样。当你有一个版本在野外,然后决定API需要更改或弃用的时候,就开始给客户端使用你的WS带来问题。

我目前正在开发一个web应用程序,其中包含一个web服务(或2个ASP.NETMVC),我强烈建议查看面向服务体系结构(SOA)背后的原则,因为我发现最重要的方面是使web服务API的设计正确无误,因为这将影响后端的其余部分让你的生活更轻松,或者让你因为沮丧而撞到墙。

与设计相比,实施更相关: 我将决定服务的输出是XML—这可以很容易地被所有合适的语言解析。另外,如果一些客户机需要其他输出,您可以通过一些XSLT处理器转换这些xml,并提供“其他”web服务,输出JSON或其他他们需要的任何东西。 关于报告,这取决于如何使用报告—如果客户机处理报告并且只需要报告中的数据—那么再次建议使用XML。在我看来,使用CSV比较困难,因为您必须考虑各种特殊情况,例如“如果我的数据包含分隔符字段会发生什么”、“客户机是否能够指定分隔符”、“我将如何表示嵌套数据”,或者所有这些都是直接使用XML的。 如果你的客户需要报告使用他们的开箱即用,你可以使用BIRT-美丽和免费的

在安全方面,任何动态处理用户提供的任何输入的东西,都应该将这些输入视为即使用棍子也不会戳到的东西。

IMHO无状态REST比SOAP好,因为它的开销更小,可以从终端使用curl或wget手动与restapi通信。可以这么说。

我建议你深吸一口气,拿一支铅笔和一张纸,坐下来把需要的东西都画下来。然后你把不太重要的东西去掉,拿一份新的论文开始整理。您可以在下一版本的API中添加不太重要的内容。

试着设计API,这样你就不会把自己锁在角落里,对它下一步的发展方向不作任何假设。