There is a great article that shows how all of the Acquia sites are architected. In that article, it is mentioned that Services is used quite a bit to power REST endpoints. Here is a really, really, useful tidbit that I don't want to forget which comes from that article.
"Is the Services Module Enough?
It’s likely that while reading this article you’ve found yourself wondering if the Services module alone was enough to pull this off. Simply put: not by a long shot. Aside from aspects of the Acquia Cloud which we leveraged to the hilt, we had to deal with a fundamental limitation of the Services module: it only listens. What Services gives us (in our case) is a REST server sitting on a Drupal site that is invoked by making PUT, POST, DELETE, or GET requests to various URLs on that Drupal site.
What we needed was the ying to Services’ yang. We needed something that would push data on a variety of hook invocations to a site running the Services module. Enter Services Client. This module has a sub-module named Services Connection that is used to define connections to remote sites running Services and also handles loop prevention. The core Services Client module hooks into user, node, taxonomy, etc., saves/updates, and then — if certain conditions (defined in the UI) are met — passes the data to the remote site.
Services Client also handles all field mapping. This means that you can map field ‘foo’ on one site to field ‘bar’ on another site. It also means that you can map between Drupal 7 core fields and Drupal 5/6 CCK fields. You read that right — Services client can talk between Drupal 5, 6, and 7. It also means that it is a fantastic way to handle an upgrade from one version of Drupal to another, that may be made easier by moving functionality from one site to another while leaving both in operation for a period of time.
A variety of other modules was also used to create this setup, such as Services Raw, Services UUID, Services Translator, UUID, and a set of custom integration modules."