在现有Web应用程序中实现REST API的策略

Question

目前我们有很多网页要么嵌入了SQL语句，要么调用特定的PHP脚本执行特定的工作 - 即getNames.php - 作为ajax回调的一部分。两者都没有特别可维护。

我正在考虑使用类似REST的API来获取客户端所需的数据，然后将数据转换为可用的数据。这很有吸引力，因为这减轻了在代码中维护高度复杂的sql的负担，并允许集中数据（所以只需要一次AJAX调用就可以获得数据而不是很多小数据）。还允许数据库更改减少对客户端的影响。

然而，我可以通过此策略看到两个问题：

1. 该网站是一款游戏，所以我需要尽可能地保护RESTlike API免受滥用/欺骗。
2. REST API的所有示例都使用控制器来处理root中的请求。这对我来说并不理想，因为我们在//公司/游戏/游戏/并且已经有一个index.php在root（// company /).

对于我列出的两个约束，我有哪些选项和策略？

Answer 1

嗯，你是在征求意见，但我已经足够经验丰富（多年来已经编写了许多API计划），我完全愿意打开自己的网络滥用。我认为这里的关键，这应该提供一个意见来解决你的两个问题，就是REST只是一套原则。当然有些人明确地遵循RESTful模式，但这对大多数人来说并不实用。

以Flickr“REST”API为例......呼叫可能如下所示：http://api.flickr.com/services/rest/?method=flickr.favorites.getContext&api_key=a114adf91150953107987e4c3dc14df8&photo_id=6033564557&format=json&nojsoncallback=1&api_sig=0d2c215992d643ef6fe4a085805f7059

从模式角度来看，它不是非常RESTful ...但是，它包含REST的所有元素，并且是一个足够好的模型。您可以一目了然地了解它的作用，并且您可以轻松地构建它。

最后，REST是一组主体，而不是协议，甚至不是模式本身。您可以随意实施它。总是有一个互操作性中间层，重点是让它变得易于理解......许多REST模式实际上都会妨碍这种形式，有利于形式而不是功能。

事实上，我所看到的大多数模式都不足以应对任何特别高级的模式，但这是REST的一部分......保持简单（愚蠢）。