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