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?


1 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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .