What are the options for building custom Apex endpoint to accept HTML form from website

Question

I know there are a lot of potential solutions for the HTML-form-to-salesforce use case, but I am trying to understand what is involved w/ building a custom endpoint to accept form data, and what alternatives I should consider.

Background:

We are doing a major website redesign (Drupal). As part of the new design, we will have a simple email signup form in the footer on all pages.

We currently use FormAssembly for all of our web forms, which works very well for most of our needs, but cannot handle multiple forms per page (the FA support team has confirmed this is not feasible. We are looking at some hacks that might make it possible, but not a great solution).

Since the email form will be in the site footer on all pages, any page with a form will always have more than one form per page.

My current line of thinking is to look at using a different avenue to submit the email signup form to Salesforce, which would resolve the two-forms-per-page issue. For speed, I would just process the result to create a custom object, and use a flow on a time trigger or an async trigger to process the result (match on contact/lead else create new).

Ideas I'm Aware Of:

• Web to lead form
• Force.com site w visualforce page
• Force.com site w/ visual workflow
• Other apps (formstack, getFeedback, wufoo, etc)
• Iframes
• Salesforce Drupal Module
• Salesforce PHP SDK

What I would like to know: Is it possible to create an apex endpoint to which I can submit a form?

Do I need to still use a force.com site to open up the endpoint? If so, does that introduce any limits or considerations.

What are the key complexities involved with or without a force.com site (authentication, limits, error handling, etc).

What are other alternatives to consider (like Heroku or other things which I do not know much about)?

Thanks as always.

Answer 1

Is it possible to create an apex endpoint to which I can submit a form?

Yes, that's one valid use of the @RestResource annotation. After all, a "REST Resource" is simply an HTTP endpoint like any other.

Do I need to still use a force.com site to open up the endpoint? If so, does that introduce any limits or considerations.

If you want to have anonymous access, then you do need a Sites.com configuration. There's daily limits on bandwidth, CPU time, and page views, but they're pretty generous for your proposed use (500k+ requests, 40GB bandwidth, and 60 hours of CPU time), which would be able to handle hundreds of thousands of submissions per day.

If you're okay with gaining a session ID somehow, then you can use the more generous internal limits (depending on how many licenses you have, of course). Since you're using Drupal, you can literally write login code in PHP and persist a session ID for you to use. I've done this before, and it's pretty easy to write up.

What are the key complexities involved with or without a force.com site (authentication, limits, error handling, etc).

The biggest concern when using Sites.com is security. You'll want to make sure that you're not allowing unauthenticated access to data, which should be pretty simple if all you're doing is recording data. You'll also probably want to verify that all requests are coming from your site (via the HTTP Referrer field). As already covered, the daily limits are pretty generous, so I don't think you'll have much of a problem.

If you're using an authenticated API, that means you have the usual API limits, CPU limits, etc, that you'd find in the Governor Limits documentation.

What are other alternatives to consider (like Heroku or other things which I do not know much about)?

You could use Heroku, but you're already running Drupal, so I don't really see a point in calling an API just to call an API, when you could call salesforce.com directly. You could just as easily decide to use an Email Service instead; just send a message by email directly to salesforce.com and it'll run your code. There's plenty of other ways you could also arrange this, but I think we've covered all the practical ones already.