Limitations in functionality of SOAP/REST/etc. API as opposed to a Force.com app?

Question

I'm still a Salesforce newbie, so I hope you won't mind my "immature" vocabulary.;)

I'm about to build an application which should be integrated with Salesforce. Currently I have two options in front of me: developing an application on Force.com platform (installed as a package) or as a standalone, Java app, communication with Salesforce through its APIs.

The use case is: the end-user should be able to select (by type of by search) a set of records (contacts, accounts, leads etc.) which may be of variable size (a couple of them but up to the complete number of records), and then send the records to a 3rd party service for processing, and then (on-demand) pull the processed records back to his account.

I've read about some pains of using the Force.com platform and their tools, but I'd like to know if there's anything in the exposed SOAP/REST APIs which isn't available when using the platform and tools themselves?

Answer 1

The short answer to the specific question "is there anything in the exposed SOAP/REST APIs which isn't available when using the platform and tools" is, for all practical purposes - no. In fact, it's usually the other way around - the external API has a number of capabilities that aren't available to a native app.

That said, I think the real question your asking is which option to choose. Whether or not a specific feature is available or unavailable in the API really isn't significant to the greater question.

The issues you really need to focus on are:

• Security. Native packages enjoy the benefits of integrated security - it's a bit more work to handle externally. If you are creating an application to market (as compared to a one-off) and you want it to appear on the Salesforce AppExchange, you'll need to pass security review, which is tough enough for managed package but much tougher for integrations.
• Synchronization and error handling. When you're a native package, the database is always accessible and in sync. When an external package you need to design a solution robust enough to handle connection errors.
• Complexity - A native app can dramatically speed your development - especially if you want it to look like the Salesforce UI for a seemless experience. It's a lot more work to implement it externally. At the same time, the native architectures needed to handle large potentially amounts of data with external callouts can be somewhat complex. So it's a tradeoff. Depending on your implementation and architecture, limits may come in to play (limits apply both to native apps and those calling into the platform - but in different ways).
• Business/cost issues. If you build your solution externally, you have to manage and maintain and pay for infrastructure (even if it is a cloud service somewhere). There are no management/maintenance costs for native apps, though there are costs if the apps are paid apps (you'll need to become familiar with the ISV program).

So, the long answer is, you have much more important issues to consider than whether a particular feature may or may not be available through the external API.