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!
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粉丝们向我说教过很多次。不好意思跑题了，让我们开始写代码。
目录：
使用PHP创建一个REST API(Createa REST API with PHP) 节选1
使用PHP创建一个REST API(Createa REST API with PHP) 节选2
使用PHP创建一个REST API(Createa REST API with PHP) 节选3
使用PHP创建一个REST API(Create aREST API with PHP) 节选4
使用PHP创建一个REST API(Createa REST API with PHP) 节选5
使用PHP创建一个REST API(Createa REST API with PHP) 节选6
530
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
