希望在PHP中開發Web服務（api），以便爲客戶提供一種與我們的平臺集成的更簡單方法。有工作流調用將通過用戶/傳遞以及一些報告選項進行驗證。開發Web服務可能帶來的一些陷阱/提示
對不起，我不能發表更多的細節或代碼的主題，我從來沒有開發的Web服務，但有經驗通過SOAP使用它們。
現在我還需要提供工作流的狀態或狀態，我認爲REST會是最好的選擇，但仍然在尋找意見。
對於報告，我想提供不同的選項，如XML，Excel/CSV任何理由我會選擇一個比其他？
我應該尋找哪些陷阱？
什麼是任何人可以提供的寶石。
在此先感謝任何幫助，因爲這對我來說是非常重要的。
更新＃1：
更新＃2： 關於數據流一點點。 每個用戶都有權使用該API並且沒有數據在用戶之間共享。用法提交請求，處理請求並返回。沒有更新。 （認爲谷歌）搜索請求，並給出結果，但在我的情況下只給出一個結果。 不知道這是否需要，所以這是一個供參考。
Always handle errors and exceptions.
問題總是會讓他們出現在應用程序/ api中。無論是在開始還是進一步發展。不要將此作爲最終任務，並在發生錯誤時將其明確，並提供詳細的響應消息。
此外，如果您的服務將處理多個請求，並且對於相同的資源ID（獨立於用戶），則返回相同的資源，請確保緩存信息。這不僅是出於性能的原因，而且還包括出現錯誤時的情況。通過這種方式，您至少可以爲客戶提供某些東西（可能有用，需要明確的更多上下文）。
另一個好的提示，thnx。儘管每個請求都是唯一的，但我不能使用緩存，但我理解這個概念背後的概念。 – 2010-10-07 13:22:18
我可以提供的最大和最重要的項目是保證您的WS背後的基礎架構，或者至少通過WS提供的服務是無狀態的。一旦你偏離了這一點，它將成爲一場噩夢，你將開始不得不使用代碼來保護你的數據不被玷污。
一個例子是兩個客戶端通過WS來更改數據，即...保存配置。如何在後端處理這些問題會讓事情變得有趣。如果您的數據只是出站，那麼如果您必須支持將數據推送到後端，則情況會更好。
此外，與任何面向公衆的API一樣深入地思考API。當你有一個版本瘋狂的時候，然後決定API需求改變或不贊成開始導致使用你的WS的客戶羣的問題。
感謝好點的思考 – 2010-10-01 15:50:11
我目前工作的一個Web應用程序，其中包括（在ASP.NET MVC或2）Web服務，我強烈建議看後面面向服務的架構（SOA）的原則爲我所發現的是，最一個重要的方面是正確設計Web服務API，因爲這會影響後端的其他部分，並讓您的生活更輕鬆，或讓您因挫折而流入牆壁。
本質上SOA意味着規避設計業務流程的Web服務，誰用你的API人即可能如何使用它。
一個好的設計總是一個好主意，所以我強烈建議你在開始編碼之前做很多關於Web服務設計原則的閱讀，並保存你自己或其他不幸的悲傷後果。
此外，請確保您的設計靈活，因爲您的公司和客戶之間的溝通會發生頻繁變化。
大提示，你可以提供什麼好的鏈接？我也會Google的主題以及 – 2010-10-08 13:21:27
http://www.soabooks.com/華夫餅有點但還是不錯的。 – eaglestorm 2010-10-10 23:17:19
和這個http://www.soaprinciples.com/ – eaglestorm 2010-10-10 23:40:34
與設計有關的實現有點多： 我認爲服務的輸出是XML--這可以通過所有體面的語言很容易解析。另外，如果某些客戶端需要其他輸出，則可以通過一些XSLT處理器來轉換這些XML，並提供「其他」Web服務，輸出JSON或其他任何他們所需的內容。 關於報告，這取決於如何使用報告 - 如果客戶端處理它們，並且他們只需要報告中的數據 - 那麼再次建議使用XML。在我看來，使用CSV更困難，因爲您必須考慮所有類型的特殊情況，例如「如果我的數據包含分隔符字段會發生什麼情況」，「客戶端能夠指定分隔符」，「我將如何表示嵌套數據「，或者所有這些都直接與XML。 如果您的客戶需要報告使用它們開箱即用，您可以使用BIRT-美麗且免費的
是的，我更傾向於xml，但也想提供JSON作爲替代。如果我同時提供這兩種方法，我認爲這不會是更多的代碼。最終用戶可以通過JSON或其他東西的可選標誌 – 2010-10-08 13:23:57
提供像JSON，CSV，YAML或XML這樣的多輸出是很好的 - 這爲終端用戶提供了一個非常小的安慰成本！轉儲數據總是比處理更容易，並且說出於某種原因他們已經解析了JSON - 與實現XML解析器相比，將API掛鉤起來要容易得多。現在我到處都可以看到XML解析器，所以這應該不是問題，但我更喜歡JSON的「空氣」特性。我看了一下YAML，但從未使用它 - 但它看起來很有希望，我將明確地將它用於我的下一個項目的配置文件。
對任何事物的安全側動態處理任何輸入的用戶提供了，一個應該把這些輸入喜歡的東西，你就不會戳甚至用棍子。
IMHO無國籍REST比SOAP更好，因爲它是較少的開銷，可以很容易地通過使用從終端捲曲或wget的手一個REST API進行通信。跳起來這麼說吧。
我會建議你深吸一口氣，用鉛筆&一張紙，坐下來畫出一切需要的東西。然後你刪除不太重要的東西，然後拿出一張新紙張並開始組織它。您可以在API的下一個版本中添加不太重要的內容。
嘗試設計的API，讓你不會自己鎖進一個角落裏，就在那裏接下來會前往任何假設。
我在想XML和JSON，但提供更多的一點點成本是另一個很好的選擇，謝謝 – 2010-10-11 13:01:07
一個簡單的建議：如果你期望你的web服務是長壽的，並且可能增長，那麼從一開始就需要一個接口的版本號。 – Wrikken 2010-10-01 13:53:10
類似api.host.com/v1/？我想我已經看到了這個，很好的提示 – 2010-10-01 13:59:58
您可以將版本存儲在URL中，也可以嵌入請求中（例如有效內部內容或標題）。另外，我真的很喜歡使用[JSON-RPC]（http://en.wikipedia.org/wiki/JSON-RPC），因爲在大多數語言中解析起來非常簡單，而且非常靈活，因爲您幾乎可以在其中嵌入任何內容JSON表示法。 REST並不是一個真正的協議，而是一種風格。因此，一個JSON-RPC請求將成爲REST調用的一種形式... SOAP和XMLRPC也是不錯的選擇，這取決於您的需求... – ircmaxell 2010-10-01 14:24:47