There's certainly nothing sick about it, save for the points derby and bart point out.

"$print" is a bit redundant :)

People quibble about GET, PUT, POST etc mapping to their logical functions for a true REST interface, but it really depends on what you expect your client to be able to understand. Everyone understands GET and POST, so I tend to use those exclusively (and still call it a REST-y interface).

Putting the 'client_key' in a header might be considered ever-so-slightly safer, in that it won't appear in a URL (regardless of SSL use), but you could just as easily require that the data be submitted with a POST by checking the method.

Is $lookup subject to SQL injection attack? I don't think so, if you're using a prepare() and parameter binding. But I could be wrong. In any case, that's something to look out for when writing a web service like this that uses a param() in a SQL statement.