使用PHP创建一个REST API(Create a REST API with PHP)
譯者前言：
首先這是一篇國外的英文文章，非常系統、詳盡的介紹了如何使用PHP創建REST API，國內這方面的資料非常非常的有限，而且基本沒有可操作性。這篇文章寫的非常好，只要對PHP稍有了解的程序員，看完本文基本可以自己動手寫 REST API，花了幾個小時翻譯過來和大家共享，希望可以幫助大家。轉載請注明出處。
本文地址：http://hmw.iteye.com/blog/1190827
原文地址：Create a REST API with PHP
One of the latest (sort of) crazes sweeping the net is APIs, more specifically those that leverage REST. It’s really no surprise either, as consuming REST APIs is so incredibly easy… in any language. It’s also incredibly easy to create them as you essentially use nothing more than an HTTP spec that has existed for ages. One of the few things that I give Rails credit for is its well thought-out REST support, both for providing and consuming these APIs (as its been explained by all the Rails fanboys I work with).
最近互聯網上比較熱門的一個名詞是APIs（接口）,特別是leverage REST。不過考慮到REST APIs在任何語言下都是非常的簡單，也就沒什么好驚奇的了。同時，它也是非常的容易創建，你基本只需要使用已經存在多年的HTTP規范就可以。我認為 Rails語言的為數不多的優點之一就是良好的REST支持，不僅是提供APIs，同時也有很多的客戶端支持（我的一些Rails粉絲同事都向我解釋了這 一點）。
Seriously, if you’ve never used REST, but you’ve ever had to work with (or worse, create) a SOAP API, or simply opened a WSDL and had your head explode, boy do I have good news for you!
認真的講，假如你從來沒有使用過REST，卻曾經使用過SOAP API，或者只是簡單的打開一個令人頭大的WSDL文檔。小伙子，我確實要帶給你一個好消息！
So, What on Earth is REST? Why Should You Care?
那么，究竟什么是REST？為什么你應該關心？
Before we get into writing some code, I want to make sure everyone’s got a good understanding of what REST is and how its great for APIs. First, technically speaking, REST isn’t specific to just APIs, it’s more of a generic concept. However, obviously, for the sake of this article we’ll be talking about it in the context of an API. So, let’s look at the basic needs of an API and how REST addresses them.
在我們開始寫代碼之前，我想要確認每個人都可以很好的理解什么是REST以及它是 如何特別適合APIs的。首先，從技術上來講，REST并不是僅僅特定于APIs應用，它更多的是一個通用的概念。然而，很明顯，我們這篇文章所討論的 REST就是在接口應用的環境下。因此，讓我們看看一個API的基本要求已經REST如何處理他們。
Requests 請求
All APIs need to accept requests. Typically, with a RESTful API, you’ll have a well-defined URL scheme. Let’s say you want to provide an API for users on your site (I know, I always use the “users” concept for my examples). Well, your URL structure would probably be something like, “api/users” and “api/users/[id]” depending on the type of operation being requested against your API. You also need to consider how you want to accept data. These days a lot of people are using JSON or XML, and I personally prefer JSON because it works well with JavaScript, and PHP has easy functionality for encoding and decoding it. If you wanted your API to be really robust, you could accept both by sniffing out the content-type of the request (i.e. application/json or application/xml), but it’s perfectly acceptable to restrict things to one content type. Heck, you could even use simple key/value pairs if you wanted.
所有的APIs都需要接收請求。對于一個RESTful API，你需要一個定義好的URL規則，我們假定你想要提供一個接口給你網站上的用戶（我知道，我總是使用"用戶"這個概念來舉例）。你的URL結構可能 類似于這樣："api/users"或者"api/users/[id]"，這取決于請求接口的操作類型。同時，你也需要考慮你想要怎么樣接收數據。近來 一段時間，很多人正在使用JSON或者XML，從我個人來講，我更加喜歡JSON，因為它可以很好的和javascript進行交互操作，同時PHP也可 以很簡單的通過json_encode和json_decode兩個函數來對它進行編碼和解碼。如果你希望自己的接口真正強健，你應該通過識別請求的內容 類型（比如application/json或者application/xml）同時允許接收兩種格式。但是，限制只接收一種類型的數據也是可以很好的 被接受。真見鬼，假如你愿意，你甚至可以使用簡單的鍵/值對。
The other piece of a request is what it’s actually meant to do, such as load, save, etc. Normally, you’d have to come up with some sort of architecture that defines what action the requester (consumer) desires, but REST simplifies that. By using HTTP request methods, or verbs, we don’t need to define anything. We can just use the GET, POST, PUT, and DELETE methods, and that covers every request we’d need. You can equate the verbs to your standard crud-style stuff: GET = load/retrieve, POST = create, PUT = update, DELETE = well, delete. It’s important to note that these verbs don’t directly translate to CRUD, but it is a good way to think about them. So, going back to the above URL examples, let’s take a look at what some possible requests could mean:
??? GET request to /api/users – List all users
??? GET request to /api/users/1 – List info for user with ID of 1
??? POST request to /api/users – Create a new user
??? PUT request to /api/users/1 – Update user with ID of 1
??? DELETE request to /api/users/1 – Delete user with ID of 1
一個請求的其他部分是它真正要做的事情，比如加載、保存等。通常來說，你應該提供 幾種結構來定義請求者（消費者）所希望的操作，但是REST簡化了這些。通過使用HTTP請求方法或者動作，我們不需要去額外定義任何東西。我們可以僅僅 使用GET,POST,PUT和DELETE方法，這些方法涵蓋了我們所需要的每一個請求。你可以把它和標準的增刪改查模式對應起來：GET=加載/檢索 (查，select)，POST=創建(增，Create)，PUT=更新(改，update),DELETE=刪除(DELETE)。我們要注意到，這 些動詞并沒有直接翻譯成CRUD（增刪改查）,但是這個理解它們的一個很好的方法。因此，回到剛才所舉的URL的例子，讓我們看一下一些可能的請求的含 義：
??? GET request to /api/users – 列舉出所有的用戶
??? GET request to /api/users/1 – 列出ID為1的用戶信息
??? POST request to /api/users – 插入一個新的用戶
??? PUT request to /api/users/1 – 更新ID為1的用戶信息
??? DELETE request to /api/users/1 – 刪除ID為1的用戶
As you hopefully see, REST has already taken care of a lot of the major headaches of creating your own API through some simple, well-understood standards and protocols, but there’s one other piece to a good API…
正如你所希望看到的，REST已經解決了很多令人頭疼的創建接口的問題，通過一些簡單的，容易理解的標準和協議。但是一個好的接口還要另外一個方面...
Responses 響應
So, REST handles requests very easily, but it also makes generating responses easy. Similar to requests, there are two main components of a RESTful response: the response body, and a status code. The response body is pretty easy to deal with. Like requests, most responses in REST are usually either JSON or XML (perhaps just plain text in the case of POSTs, but we’ll cover that later). And, like requests, the consumer can specify the response type they’d like through another part of the HTTP request spec, “Accept”. If a consumer wishes to receive an XML response, they’d just send an Accept header as a part of their request saying as much (”Accept: application/xml”). Admittedly, this method isn’t as widely adopted (tho it should be), so you have can also use the concept of an extension in the URL. For example, /api/users.xml means the consumer wants XML as a response, similarly /api/users.json means JSON (same for things like /api/users/1.json/xml). Either way you choose (I say do both), you should pick a default response type as a lot of the time people wont’ even tell you what they want. Again, I’d say go with JSON. So, no Accept header or extension (i.e. /api/users) should not fail, it should just fail-over to the default response-type.
所以，REST可以很簡單的處理請求，同時它也可以簡單的處理響應。和請求類似， 一個RESTful的響應主要包括兩個主要部分：響應體和狀態碼。響應體非常容易去處理。就像請求，大部分的REST響應通常是JSON或者XML格式 （也許對POST操作來說僅僅是純文本，我們稍后會討論），和請求類似，消費者可以通過設置HTTP規范的"Accept"選項來規定自己做希望接收到的 響應數據類型。如果一個消費者希望接收到XML響應，他們僅僅需要發送一個包含類似于(”Accept: application/xml”)這樣的頭信息請求。不可否認，這種方式并沒有被廣泛的采用（即使應該這樣），因此你也可以使用URL后綴的形式，例 如：/api/users.xml意味著消費者希望得到XML響應，同樣，/api/users.json意味著JSON格式的響應（/api /users/1.json/xml也是一樣）。不管你采用哪一種方法，你都需要設定一個默認的響應類型，因為很多時候人們并不會告訴你他們希望什么格 式。再次地，我會選擇JSON來討論。所以，沒有Accept頭信息或者擴展（例如：/api/users）不應該失敗，而是采用默認的響應類型。
But what about errors and other important status messages associated with requests? Easy, use HTTP status codes! This is far and above one of my favorite things about creating RESTful APIs. By using HTTP status codes, you don’t need to come up with a error / success scheme for your API, it’s already done for you. For example, if a consumer POSTS to /api/users and you want to report back a successful creation, simply send a 201 status code (201 = Created). If it failed, send a 500 if it failed on your end (500 = Internal Server Error), or perhaps a 400 if they screwed up (400 = Bad request). Maybe they’re trying to POST against an API endpoint that doesn’t accept posts… send a 501 (Not implemented). Perhaps your MySQL server is down, so your API is temporarily borked… send a 503 (Service unavailable). Hopefully, you get the idea. If you’d like to read up a bit on status codes, check them out on wikipedia: List of HTTP Status Codes.
但是和請求有關的錯誤和其他重要的狀態信息怎么辦呢？簡單，使用HTTP的狀態 碼！這是我創建RESTful接口最喜歡的事情之一。通過使用HTTP狀態碼，你不需要為你的接口想出error/success規則，它已經為你做好。 比如：假如一個消費者提交數據（POST）到/api/users，你需要返回一個成功創建的消息，此時你可以簡單的發送一個201狀態碼 （201=Created)。如果失敗了，服務器端失敗就發送一個500（500=內部服務器錯誤），如果請求中斷就發送一個400（400=錯誤請 求）。也許他們會嘗試向一個不接受POST請求的接口提交數據，你就可以發送一個501錯誤（未執行）。又或者你的MySQL服務器掛了，接口也會臨時性 的中斷，發送一個503錯誤（服務不可用）。幸運的是，你已經知道了這些，假如你想要了解更多關于狀態碼的資料，可以在維基百科上查找：List of HTTP Status Codes。
I’m hoping you see all the advantages you get by leveraging the concepts of REST for your APIs. It really is super-cool, and its a shame its not more widely talked about in the PHP community (at least as far as I can tell). I think this is likely due to the lack of good documentation on how to deal with requests that aren’t GET or POST, namely PUT and DELETE. Admittedly, it is a bit goofy dealing with these, but it certainly isn’t hard. I’m also sure some of the popular frameworks out there probably have some sort of REST implementation, but I’m not a huge framework fan (for a lot of reasons that I won’t get into), and it’s also good to know these things even if somebody’s already created the solution for you.
我希望你能看到REST接口的這些優點。它真的超級酷。在PHP社區社區里沒有被 廣泛的討論真是非常的遺憾（至少我知道的是這樣）。我覺得這主要是由于沒有很好的文檔介紹如何處理除了GET和POST之后的請求，即PUT和 DELETE。不可否認，處理這些是有點傻，但是卻不難。我相信一些流行的框架也許已經有了某種REST的實現方式，但是我不是一個框架粉絲（原因有很 多），并且即使有人已經為你提供了解決方案，你知道這些也是非常有好處的。
If you’re still not convinced that this is a useful API paradigm, take a look at what REST has done for Ruby on Rails. One of its major claims to fame is how easy it is to create APIs (through some sort of RoR voodoo, I’m sure), and rightly so. Granted I know very little about RoR, but the fanboys around the office have preached this point to me many times. But, I digress… let’s write some code!
如果你還是不太自信這是一個非常有用的API范式，看一下REST已經為Ruby on Rails做了什么。其中最令人稱道的就是創建接口的便利性（通過某種RoR voodoo，我確信），而且確實如此。雖然我對RoR了解很少，但是辦公室的Ruby粉絲們向我說教過很多次。不好意思跑題了，讓我們開始寫代碼。
Getting Started with REST and PHP 開始使用PHP寫REST
One last disclaimer: the code we’re about to go over is in no way intended to be used as an example of a robust solution. My main goal here is to show how to deal with the individual components of REST in PHP, and leave creating the final solution up to you.
最后一項免責聲明：我們接下來提供的代碼并不能被用來作為一個穩健的解決方案。我的主要目的是向大家展示如果使用PHP處理REST的每個單獨部分，而把最后的解決方案留給你們自己去創建。
So, let’s dig in! I think the best way to do something practical is to create a class that will provide all the utility functions we need to create a REST API. We’ll also create a small class for storing our data. You could also then take this, extend it, and apply it to your own needs. So, let’s stub some stuff out:
那么，讓我們開始深入代碼。我認為做一個實際事情做好的方法就是新建一個 class，這個class將提供創建REST API所需要的所有功能性方法。現在我們新建一個小的class來存儲我們的數據。你可以把它拿去擴展一下然后應用到自己的需求中。我們現在開始寫點東 西：
?
?OK, so what we’ve got is a simple class for storing some information about our request (RestRequest), and a class with some static functions we can use to deal with requests and responses. As you can see, we really only have two functions to write… which is the beauty of this whole thing! Right, let’s move on…
Processing the Request
好，現在我們有了一個簡單的class來存儲request的一些信息（RestRequest），和一個提供幾個靜態方法的class來處理請求和響應。就像你能看到的，我們還有兩個方法要去寫，這才是整個代碼的關鍵所在，讓我們繼續...
Processing the request is pretty straight-forward, but this is where we can run into a few catches (namely with PUT and DELETE… mostly PUT). We’ll go over those in a moment, but let’s examine the RestRequest class a bit. If you’ll look at the constructor, you’ll see that we’re already interpreting the HTTP_ACCEPT header, and defaulting to JSON if none is provided. With that out of the way, we need only deal with the incoming data.
處理請求的過程非常直接，但是這才是我們可以有所收獲的地方（即 PUT/DELETE，大多數是PUT），我們接下來將會討論這些。但是讓我們先來檢查一下RestRequest這個class，在構造方法中，你會看 到我們已經處理了HTTP_ACCEPT的頭信息，并且將JSON作為默認值。這樣，我們就只需要處理傳入的數據。
There are a few ways we could go about doing this, but let’s just assume that we’ll always get a key/value pair in our request: ‘data’ => actual data. Let’s also assume that the actual data will be JSON. As stated in my previous explanation of REST, you could look at the content-type of the request and deal with either JSON or XML, but let’s keep it simple for now. So, our process request function will end up looking something like this:
我們有幾個方法可以選擇，但是讓我們假設在請求信息的總是可以接收到鍵/值 對：'data'=>真實數據。同時假設真實數據是JSON格式的。正如我前文所述，你可以根據請求的內容類型來處理JSON或者XML，但是讓我 們現在簡單一點。那么，我們處理請求的方法將會類似于這樣：
?Like I said, pretty straight-forward. However, a few things to note… First, you typically don’t accept data for DELETE requests, so we don’t have a case for them in the switch. Second, you’ll notice that we store both the request variables, and the parsed JSON data. This is useful as you may have other stuff as a part of your request (say an API key or something) that isn’t truly the data itself (like a new user’s name, email, etc.).
正如我剛才所說的，非常的簡單直接高效。然后，有幾點需要注意：首先，我們不接受 DELETE請求，因此我們在switch中不提供相應的case條件。其次，你會注意到我們把請求參數和解析后的JSON數據都存儲起來了，這在請求中 有其他需要處理的數據時會變得非常有用（API key或者其他），這些并不是請求的數據本身（比如一個新用戶的名字、電子郵箱等）。
So, how would we use this? Let’s go back to the user example. Assuming you’ve routed your request to the correct controller for users, we could have some code like this:
那么，我們如何使用它呢？讓我們回到剛才user的例子。假設你已經通過路由把請求對應到正確的users控制器，代碼如下：
?Please don’t do this in a real app, this is just a quick-and-dirty example. You’d want to wrap this up in a nice control structure with everything abstracted properly, but this should help you get an idea of how to use this stuff. But I digress, let’s move on to sending a response.
Sending the Response
請不要在真實的應用中這樣做，這是一個非常快速和不干凈的示例。你應該使用一個設計良好的控制結構來把它包裹起來，適當的抽象化，但是這樣有助于你理解如何使用這些東西。讓我們繼續代碼，發送一個響應信息。
Now that we can interpret the request, let’s move on to sending the response. We already know that all we really need to do is send the correct status code, and maybe some body (if this were a GET request, for example), but there is an important catch to responses that have no body. Say somebody made a request against our sample user API for a user that doesn’t exist (i.e. api/user/123). The appropriate status code to send is a 404 in this case, but simply sending the status code in the headers isn’t enough. If you viewed that page in your web browser, you would get a blank screen. This is because Apache (or whatever your web server runs on) isn’t sending the status code, so there’s no status page. We’ll need to take this into account when we build out our function. Keeping all that in mind, here’s what the code should look like:
既然我們已經可以解析請求，那么接下來我們繼續來發送一個響應。我們已經知道我們 真正需要去做的是發送一個正確的狀態碼和一些響應消息體（例如這是一個GET請求），但是對于沒有消息體的響應來說有一個重要的catch（譯者：不好意 思，實在是不知道如何翻譯這個詞）。假定某個人向我們的user接口發送一個請求某個用戶信息的請求，而這個用戶卻不存在（比如：api/user /123），此時系統發送最合適的狀態碼是404。但是簡單的在頭信息中發送狀態碼是不夠的，如果你通過網頁瀏覽器瀏覽該頁面，你會看到一個空白頁面。這 是因為apache服務器（或者其他服務器）并不會發送此狀態碼，因此沒有狀態頁面。我們需要在構建方法的時候考慮到這一點。把所有的東西都考慮進去，代 碼會類似于下面這樣：
?That’s It! We technically have everything we need now to process requests and send responses. Let’s talk a bit more about why we need to have a standard body response or a custom one. For GET requests, this is pretty obvious, we need to send XML / JSON content instead of a status page (provided the request was valid). However, there’s also POSTs to deal with. Inside of your apps, when you create a new entity, you probably fetch the new entity’s ID via something like mysql_insert_id(). Well, if a user posts to your API, they’ll probably want that new ID as well. What I’ll usually do in this case is simply send the new ID as the body (with a 201 status code), but you could also wrap that in XML or JSON if you’d like.
就這樣，從技術上來說，我們已經具備了處理請求和發送響應的所有東西。下面我們再 討論以下為什么我們需要一個標準的相應提或者一個自定義的。對于GET請求來說，非常明顯，我們需要發送XML/JSON內容而不是一個狀態頁（假設請求 是合法的）。然后，我們還有POST請求要去處理。在你的應用內部，當你創建一個新的實體，你也許需要使用通過類似于mysql_insert_id() 這樣的函數得到這個實體的ID。那么，當一個用戶提交到你的接口，他們將很可能想要知道這個新的ID是什么。在這種情況下，我通常的做法是非常簡單的把這 個新ID作為響應的消息體發送給用戶（同時發送一個201的狀態碼頭信息），但是如果你愿意，你也可以使用XML或者JSON來把它包裹起來。
So, let’s extend our sample implementation a bit:
現在，讓我們來擴展一下我們的例子，讓它更加實際一點：
?Again, this is just an example, but it does show off (I think, at least) how little effort it takes to implement RESTful stuff.
Wrapping Up
再一次說明，這是一個例子，但它確實向我們展示了（至少我認為是）它能輕而易舉的實現RESTful接口。
So, that’s about it. I’m pretty confident that I’ve beaten the point that this should be quite easy into the ground, so I’d like to close with how you can take this stuff further and perhaps properly implement it.
所以，這就是它。我非常的自信的說，我已經把這些解釋的非常清楚。因此，我就不再贅述你如何具體實現它。
In a real-world MVC application, what you would probably want to do is set up a controller for your API that loads individual API controllers. For example, using the above stuff, we’d possibly create a UserRestController which had four methods: get(), put(), post(), and delete(). The API controller would look at the request and determine which method to invoke on that controller. That method would then use the utils to process the request, do what it needs to do data-wise, then use the utils to send a response.
在一個真實的MVC應用中，也許你想要做的就是為你的每個接口創建一個單獨的控制 器。例如，利用上面的東西，我們可以創建一個UserRestController控制器，這個控制器有四個方法，分別為：get(), put(), post(), 和 delete()。接口控制器將會查看請求類型然后決定哪個方法會被執行。這個方法會再使用工具來處理請求，處理數據，然后使用工具發送響應。
You could also take it a step further than that, and abstract out your API controller and data models a bit more. Rather than explicitly creating a controller for every data model in your app, you could add some logic into your API controller to first look for an explicitly defined controller, and if none is found, try to look for an existing model. For example, the url “api/user/1″, would first trigger a lookup for a “user” rest controller. If none is found, it could then look for a model called “user” in your app. If one is found, you could write up a bit of automated voodoo to automatically process all the requests against those models.
你也許會比現在更進一步，把你的接口控制器和數據模型抽象出來，而不是明確的為每 一個數據模型創建控制器，你可以給你的接口控制器添加一些邏輯，先去查找一個明確定義好的控制器，如果沒有，試著去查找一個已經存在的模型。例如：網 址"api/user/1"將會首先觸發查找一個叫user的最終控制器，如果沒有，它會查找應用中叫user的模型，如果找到了，你可以寫一個自動化的 方法來自動處理所有請求這個模型的請求。
Going even further, you could then make a generic “list-all” method that works similar to the previous paragraph’s example. Say your url was “api/users”. The API controller could first check for a “users” rest controller, and if none was found, recognize that users is pluaralized, depluralize it, and then look for a “user” model. If one’s found, load a list the list of users and send that off.
再進一步，你可以建立一個通用的"list-all"方法，就像上面一段中的例子 一樣。假定你的url是"api/usrs"，接口控制器首先會查找叫users的控制器，如果沒有找到，確認users是復數，把它變成單數，然后查找 一個叫user的模型，如果找到了，加載一個用戶列表然后把他們發送出去。
Finally, you could add digest authentication to your API quite easily as well. Say you only wanted properly authenticated users to access your API, well, you could throw some code like this into your process request functionality (borrowed from an existing app of mine, so there’s some constants and variables referenced that aren’t defined in this snippet):
最后，你可以給你的接口添加簡單的身份驗證。假定你僅僅希望適當的驗證訪問你的接口的用戶，那么，你可以在處理請求的方法中添加類似于下面的一些代碼（借用我的一個現有應用，因此有一些常量和變量在這個代碼片段里面并沒有被定義）：
?Pretty cool stuff, huh? With a little bit of code and some clever logic, you can add a fully functional REST API to your apps very quickly. I’m not just saying that to cheerlead the concept either, I implemented this stuff into one of my personal frameworks in about half a day, and then spent another half day adding all sorts of cool magic to it. If you (the reader) are interested in seeing my final implementation, drop me a note in the comments and I’d be happy to share it with you! Also, if you’ve got any cool ideas you’d like to share, be sure to drop those in the comments as well… if I like it enough, I’d even let you guest author your own article on the subject!
非常酷，對吧？通過少量的代碼和一些智能的邏輯，你可以非常快速的給你的應用添加 全功能的REST接口。我并不僅僅是支持這個概念，我已經在我個人的框架里面實現了這些東西，而這些僅僅花費了半天的時間，然后再花費半天時間添加一些非 常酷的東西。如果你（讀者）對我最終的實現感興趣，請在評論中留言，我會非常樂趣和你分享它。同時，如果你有什么比較酷的想法，也歡迎通過評論和我進行分 享。如果我足夠喜歡它，我會邀請你在這里發表自己的文章。
?
轉載于:https://www.cnblogs.com/kudosharry/articles/2550366.html
總結
以上是生活随笔為你收集整理的使用PHP创建一个REST API(Create a REST API with PHP)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 废铝多少钱啊？
- 下一篇： 永劫无间绝代风华怎么获得