Strategies for implementing a REST like API in an existing web-application

Currently we have a lot of web pages that either have SQL statements embedded in them or call a specific php script that does a specific job - ie getNames.php - as part of a ajax call back. Neither are particularly maintainable.

I was thinking about using a REST like API to get the necessary data to the client and then munge the data into something usable. This is attractive as this lessens the burden on maintaining highly complex sql in code and allows centralisation of data (so just one AJAX call to get the data not lots 开发者_如何学Cof little ones). Also allows the database to change lessening the impact on the client.

However there are two problems I can see with this strategy:

1. The site is a game, and so I need the RESTlike API to be protected from abuse/cheating as much as possible.
2. All examples of REST API's use a controller to handle the requests in root. That's not ideal for me since we are at //company/games/game/ and there already is an index.php at root (//company/).

What options and strategies do I have for the two constraints I listed?

Well, you're asking for opinion, but I'm well seasoned enough (having written many many API schemes over the years) that I'm totally willing to open myself up to Net abuse. I think the key here, and this should provide an opinion to work from on both of your questions, is that REST is simply a set of principles. Sure there are people that follow a RESTful pattern explicitly, but that isn't practical for most people.

Take the Flickr "REST" API for instance... a call may look like this: http://api.flickr.com/services/rest/?method=flickr.favorites.getContext&api_key=a114adf91150953107987e4c3dc14df8&photo_id=6033564557&format=json&nojsoncallback=1&api_sig=0d2c215992d643ef6fe4a085805f7059

Not very RESTful, from a patterning perspective... however, it contains all of the elements of REST and is a fine enough model. You can understand what it is doing at a glance, and you can easily build on top of that.

IN the end, REST is a set of principals, not a protocol, and not even a pattern in and of itself. You're free to implement it however you want. There's always an interoperability intermediate layer and the point is to just make it understandable... and many of the REST patterns actually get in the way of that, favoring form over function.

In fact, most of the patterns I've seen are insufficient for anything particularly advanced, but that's part of the point of REST... Keep It Simple (Stupid).