What are the reasons to use a Visualforce page on Force.com Sites versus a @RestResource to accept incoming REST calls?

Question

I'm experimenting with an app that creates a new SMS record in Salesforce when an SMS comes in to a number in Twilio. It seems that there are two commonly accepted ways to do this:

1. Create a Force.com Site with a Visualforce page whose Apex controller handles the incoming REST.
2. Create a Force.com Site with a (public) custom @RestResource to handle the incoming REST.

It seems that the setup is largely the same in both cases: I would want to verify the Twilio request, use a permission set CRUD and other access permissions, etc.

The advantage to me seems to be to use a @RestResource, because it doesn't require creating Visualforce pages that have no content and just route the request to Apex. But most examples I've seen have gone the Visualforce page route -- even using multiple pages to accept different requests -- so I'm wondering if there's something I'm missing?

Answer 1

Historically the ability to expose APIs as publicly accessible via sites wasn't very well known, which might have lead to a lot of REST-like visualforce pages by those simply ignorant of the neat feature hidden in sites.

Literacy has risen since then, and you can find examples of both, but if you see a lopsided number of historical posts that might well explain it.

The other possibly issue is that I believe, and will try to confirm later, that public API hits via sites count both as a site page view AND an API call. Since they're both metered resources it makes sense from a scalability perspective (and since we're cloud scalability mostly means money here) to use only one metered resource when possible.