Php 在现有web应用程序中实现REST类API的策略

目前，我们有很多网页，要么内嵌SQL语句，要么调用执行特定任务的特定php脚本（即getNames.php），作为ajax回调的一部分。两者都不是特别可维护的

我在考虑使用一个类似REST的API将必要的数据提供给客户端，然后将数据转换成可用的东西。这很有吸引力，因为它减轻了在代码中维护高度复杂的sql的负担，并允许集中数据，因此只需一个AJAX调用即可获取数据，而不是大量的小数据。还允许更改数据库，以减少对客户端的影响

然而，我可以看到，这一策略存在两个问题：

该站点是一个游戏，因此我需要尽可能保护RESTlike API免受滥用/欺骗。 RESTAPI的所有示例都使用一个控制器来处理根目录中的请求。这对我来说并不理想，因为我们位于//company/games/game/，并且在root//company/上已经有一个index.php。

---

对于我列出的两个约束条件，我有什么选择和策略？

好吧，你是在征求意见，但我经验丰富，多年来编写了许多API方案，我完全愿意让自己暴露在网络滥用的面前。我认为这里的关键，这应该为你的两个问题提供一个观点，就是REST只是一套原则。当然有人明确遵循RESTful模式，但这对大多数人来说并不实用

以Flickr REST API为例。。。电话可能如下所示：

从模式的角度来看，不是很安静。。。但是，它包含REST的所有元素，是一个足够好的模型。您可以一眼就了解它在做什么，并且可以轻松地在此基础上进行构建

最后，REST是一组主体，而不是一个协议，甚至其本身也不是一种模式。你可以随意地实现它。总有一个互操作性中间层，关键是要让它易于理解。。。许多REST模式实际上阻碍了这一点，它们更倾向于形式而不是功能

---

事实上，我所看到的大多数模式对于任何特别高级的东西都是不够的，但这是休息点的一部分。。。保持简单愚蠢。

没有理由不能在子目录中使用字体控制器。。。您只需要正确地配置它。不过，这个模式仍然有效。你能用一个答案来充实一下吗？我如何设置它，以便使用//公司/游戏/游戏/休息作为控制器？啊，好的。大多数网站都有/表/行/项作为其选择标准。老实说，我从来都不喜欢这种命名方案？xxx=yyy&zzz=www&etc，但如果它奏效的话……如果再加上任何浏览页面源代码并看到//api.company/的人，那就太过分了。我不确定你的观点是否正确。如果使用AJAX，该API无论如何都会公开。我构建的大多数大型项目都是这样的，即网站在内部是API的使用者，但当它到达客户机时，就没有任何迹象了。它为我提供了将数据序列化为JSON或XML的灵活性，有时用于AJAX，有时用于页面级JS。虽然您可能对它的功能有所了解，但只能获取修复脚本返回的数据。通过api方法返回表中的所有数据，用户可以自己提取数据并编写脚本来为他玩游戏——这是我们不想要的。当然，但我认为，如果说不能用你拥有的来完成这项工作，那是一个白日梦。Greasemonkey在这方面做得很好。如果您相信API会使它变得更简单，那么它可能会。您最好的选择可能是在与每次鼠标单击相关联的临时值上使用滚动加密方案。你可以很容易地重新创建你拥有的API，方法是只将你的API设置为私有的，并使用一个与你建议的类似的密钥系统。。。所有这些都是进入壁垒，总比没有壁垒好。