The problem I see with your approach is that you are building a REST API for only one consumer, your controllers, and that’s overkill. Don’t just add a layer just to pass data from one layer to another, there’s no point, you’ll be creating work for yourself for no additional benefit.

One (quick) way to make your API useful would be if it was the only endpoint your controllers (i.e. your application) ever needs. Consider this:

Suddenly your REST API has a purpose, and that is to provide a unified interface to your various data providers. Your application doesn’t need to know about the Google or the Trello API, or any other data provider you might use in the future, it just needs to know about your REST API.

This design, albeit slightly more useful, is still overkill if your application is the only consumer. The whole point of building a REST API is to expose a publicly available interface for your applications to share. And the key here is exposure, your REST API will be available to the world and therefore it must be secure. API authentication and authorization are no simple tasks, if only one application uses your API, why go through all the trouble? Unless of course you want to experiment and learn. If that’s the case, by all means go for it.

In any case, performance shouldn’t be an issue. You’d be adding an extra layer, so obviously there will be some overhead, but whether that overhead will be significant or not depends entirely on your implementation. If your REST API is the single endpoint, then it will probably be a good idea to also be the one place where caching happens. And not just server side caching, a REST API makes browser caching a bit more easier to exploit, and if you get it right, the overall performance of your application may increase, comparing to a non REST approach.

tl;dr: Don’t build stuff that don’t have an actual purpose (unless you’re learning).

Based on your drawing, it seems like there should be a model called by your controller that deals with talking to Google, getting the results back, formatting it for your app, and then that is sent to controller ready to go. In other words all the google specific details would be in that model. same for trello. that way if you need to add more apis to consume, you have kept everything nice and separate.

this is a small detail – but remember in your overall app design – you have to account for possible delays in sending / getting the information from the api server to your server. in other words make sure your app doesnt completely hang up if the trello server is slow or down.

Apis have to be concerned with security but they don’t necessarily have to be ‘public’. many apis are business to business with nothing public.

i’ve read most of this book – its short, still early release, and not enough examples – but its very current, its all php, and the author is actively creating and teaching about apis.
http://shop.oreilly.com/product/0636920028291.do

the author has php rest api related posts on her blog.
http://www.lornajane.net/blog

and be sure and read the comments for the api posts! seriously it will give you very valuable perspective.

Suggest that you google “hypermedia” and api. you might not want to use it, but it will show you some other techniques for api creation.

I’ve just joined programmers – i would upvote this question if i could! most businesses will not be able to create entirely new applications for consuming or publishing apis. so coming up with best practices for integrating apis into existing mvc frameworks — this is really important.