希望在PHP中开发Web服务（api），为客户提供更轻松的方式来集成我们的平台。有工作流程调用将通过user / pass以及一些报告选项进行验证。
很抱歉，我无法发布有关该主题的更多详细信息或代码，我从未开发过Web服务，但有过通过SOAP使用它们的经验。
现在我还需要提供工作流程的状态或状态，我认为REST将是这里的最佳选择，但仍然在寻找意见。
对于报告，我想提供不同的选项，例如XML，Excel / CSV，我会选择其中一种吗？
我应该注意哪些陷阱？
任何人都可以提供什么宝石。
提前感谢任何帮助，因为这对我来说非常重要。
更新＃1：
更新＃2： 关于数据流的一点点。 每个用户都有使用API的信誉，用户之间不共享数据。用法是提交请求，处理请求并返回。没有更新。 （想想Google）会发出搜索请求并给出结果，但在我的情况下，只给出了一个结果。 不知道这是否需要，所以这是一个FYI。
答案 0 :(得分：4)
Always handle errors and exceptions.
问题将始终在应用程序/ api中感受到它们的存在。无论是在开始还是通过进一步发展。不要将此作为最终任务，并在发生错误时明确说明，并记录良好的响应消息。
此外，如果您的服务将处理许多请求，并且对于相同的资源ID（独立于用户），将返回相同的资源，请务必缓存该信息。这不仅是出于性能原因，而且是出现错误的情况。这种方式至少可以为客户提供服务（可能有用，需要明确的更多上下文）。
答案 1 :(得分：2)
我能提供的最大和最重要的项目是保证您的基础设施落后于WS，或者至少通过WS提供的服务是无状态的。当你偏离它的那一刻，它将成为一场噩梦，你将开始不得不使用代码来保护你的数据免受污染。
一个例子是两个客户端通过WS对数据进行更改，即...保存配置。你如何在后端处理它会让事情变得有趣。如果您的数据只是出站，那么如果您必须支持将数据推送到后端，那么您处于更好的状态。
此外，与任何面向公众的API一样，深入考虑API。你有一个版本，然后决定API需求被改变或弃用的那一刻开始导致客户群使用你的WS的问题。
答案 2 :(得分：2)
我目前正在开发一个包含Web服务（或ASP.NET MVC中的2个）的Web应用程序，我强烈建议您查看面向服务的体系结构（SOA）背后的原理，因为我发现最重要的是方面是让Web服务API的设计更正确，因为这将影响你的后端的其余部分，或者让你的生活变得更轻松，或者让你在挫折中遇到困境。
本质上，SOA意味着围绕业务流程设计Web服务，即使用API的人员可能如何使用它。
一个好的设计总是一个好主意，所以我强烈建议你在开始编码之前做很多关于Web服务设计原则的阅读，以及后来保存自己或其他一些不幸的草皮。
同时确保您的设计灵活，因为当您的公司与客户之间的沟通发生时，它会经常变化。
答案 3 :(得分：2)
与实现相比，与设计有关： 我认为服务的输出是XML - 这可以很容易地被所有体面的语言解析。此外，如果某些客户端需要其他输出，您可以通过某些XSLT处理器转换这些XML，并提供输出JSON或其他任何需要的“其他”Web服务。 关于报告，这取决于报告的使用方式 - 如果客户端处理它们并且只需要报告中的数据 - 那么再次建议使用XML。在我看来，使用CSV更难，因为你必须考虑所有类型的特殊情况，例如“如果我的数据包含分隔符字段会发生什么”，“客户端是否能够指定分隔符”，“我将如何表示嵌套数据“，或者所有这些都是XML直接的。 如果您的客户需要使用开箱即用的报告，您可以使用BIRT -beautiful和free
答案 4 :(得分：2)
提供多种输出，如JSON，CSV，YAML或XML，这样可以以极低的成本为最终用户提供帮助！转储数据总是比处理更容易，并且说它们已经出于某种原因解析了JSON--比起实现，比如XML解析器更容易为你的API挂钩。现在我到处都看到XML解析器，所以这应该不是问题，但我更喜欢JSON的“空气”性质;我看了一下YAML，但从未使用它 - 但看起来很有希望，我明确地将它用于我下一个项目的配置文件。
在动态处理用户提供的任何输入的任何内容的安全方面，应该将这样的输入视为即使用棍子也不会戳的东西。
IMHO无状态REST优于SOAP，因为它的开销较小，可以使用来自终端的curl或wget手动与REST-api进行通信。跳起来就这么说。
我会建议你深吸一口气，一支铅笔＆amp;一篇论文，坐下来，草拟下所需要的一切。然后你删除不那么重要的东西，拿一张新纸开始组织它。您可以在下一版API中添加不太重要的内容。
尝试设计API，这样就不会将自己锁定在角落里，也不会假设下一步该去哪里。