目前，我们有很多网页要么嵌入SQL语句，要么调用特定的php脚本来完成特定的工作-例如getNames.php -作为ajax回调的一部分。两者都不是特别可维护的。
我正在考虑使用REST之类的API将必要的数据获取到客户端，然后将数据更改为可用的东西。这很有吸引力，因为这减少了在代码中维护高度复杂的sql的负担，并允许数据集中(因此只需一个AJAX调用即可获得数据，而不是许多小的调用)。还允许数据库更改，减少对客户端的影响。
然而，我发现这个策略有两个问题:
- 该网站是一个游戏，所以我需要rest样的API来防止滥用/欺骗尽可能多的保护。
- 所有REST API的例子都使用控制器来处理根中的请求。这对我来说并不理想，因为我们在//company/games/game/，已经有一个index.php在根目录(//company/)。
对于我列出的两个约束，我有什么选择和策略?
好吧，你是在征求意见，但我经验丰富(多年来编写了许多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的一部分意义……保持简单(愚蠢)。