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!
你也许会比现在更进一步，把你的接口控制器和数据模型抽象出来，而不是明确的为每一个数据模型创建控制器，你可以给你的接口控制器添加一些逻辑，先去查找一个明确定义好的控制器，如果没有，试着去查找一个已经存在的模型。例如：网址"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):
最后，你可以给你的接口添加简单的身份验证。假定你仅仅希望适当的验证访问你的接口的用户，那么，你可以在处理请求的方法中添加类似于下面的一些代码（借用我的一个现有应用，因此有一些常量和变量在这个代码片段里面并没有被定义）：
- // figure out if we need to challenge the user
- if(emptyempty($_SERVER['PHP_AUTH_DIGEST']))
- {
- header('HTTP/1.1 401 Unauthorized');
- header('WWW-Authenticate: Digest realm="' . AUTH_REALM . '",qop="auth",nonce="' . uniqid() . '",opaque="' . md5(AUTH_REALM) . '"');
- // show the error if they hit cancel
- die(RestControllerLib::error(401, true));
- }
- // now, analayze the PHP_AUTH_DIGEST var
- if(!($data = http_digest_parse($_SERVER['PHP_AUTH_DIGEST'])) || $auth_username != $data['username'])
- {
- // show the error due to bad auth
- die(RestUtils::sendResponse(401));
- }
- // so far, everything's good, let's now check the response a bit more...
- $A1 = md5($data['username'] . ':' . AUTH_REALM . ':' . $auth_pass);
- $A2 = md5($_SERVER['REQUEST_METHOD'] . ':' . $data['uri']);
- $valid_response = md5($A1 . ':' . $data['nonce'] . ':' . $data['nc'] . ':' . $data['cnonce'] . ':' . $data['qop'] . ':' . $A2);
- // last check..
- if($data['response'] != $valid_response)
- {
- die(RestUtils::sendResponse(401));
- }
非常酷，对吧？通过少量的代码和一些智能的逻辑，你可以非常快速的给你的应用添加全功能的REST接口。我并不仅仅是支持这个概念，我已经在我个人的框架里面实现了这些东西，而这些仅仅花费了半天的时间，然后再花费半天时间添加一些非常酷的东西。如果你（读者）对我最终的实现感兴趣，请在评论中留言，我会非常乐趣和你分享它。同时，如果你有什么比较酷的想法，也欢迎通过评论和我进行分享。如果我足够喜欢它，我会邀请你在这里发表自己的文章。
目录：
使用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
扫一扫
2925
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
