Support the new REST API

Hmm...REST API might be easier to use, but would be a very different approach, I think. Might require abstracting the mapping UI from the export API.

The biggest change will be implementing REST authentication -- the process is wholly different than SOAP auth and would require new UI/UX development.

Otherwise, in theory, implementing REST API should be as simple as writing a new PHP Toolkit library -- based on REST instead of SOAP -- and dropping it in place of the SOAP toolkit.

Simply put, the PHP Toolkit is a wrapper for a SalesForce web service, and from what I've seen the REST web service is not drastically different from the SOAP service. The most important methods -- CRUD, Describe, Query -- are still available. The features that REST does not expose (e.g. getDeleted(), merge()) are not implemented by the salesforce module anyway. (Developers who rely on these SOAP-only functions are apparently out of luck if they switch to REST.)

Moreover, the Drupal salesforce module shouldn't care about the mechanism of that web service - it should merely provide an adapter for the wrapper. I say "in theory" and "should" because I'm not 100% positive that the layers in the Drupal module are implemented as discretely as they should be.
Make sense?

I'm moving this down to the 6.x branch on the assumption that changes are being made there that will be forward-ported to 7.x (since the 6.x branch is substantially ahead of 7.x now, both in terms of testing and features/UX).

Here's a recent developer post from Pat Patterson (metadaddy on IRC & Github) about how to do the OAuth authentication: http://developer.force.com/cookbook/recipe/interact-with-the-forcecom-re.... We'd have to translate this into a Drupal idiom to use the REST API. Then, we'd have to figure out whether the wrapper functions in Salesforce API module were really abstract enough to handle REST vs. SOAP.

I have already started working on a REST wrapper.
I'll post updates here when it's out of the incubator.

Awesome!

Couldn't we leverage the OAuth module and or because the the requirements for tight integration I could see just requiring the oauth-php library.

http://drupal.org/project/oauth
http://code.google.com/p/oauth2-php/
http://drupalmodules.com/module/services-oauth

Also instead of rolling your own why not leverage the rest server module (powered by the services module)?

http://drupalmodules.com/module/rest-server
http://drupalmodules.com/module/services
http://drupalmodules.com/module/web-service-clients

These sound like promising ideas, but I probably won't have time to work on this in the near future

@aaronbauman: Any interest in this still? This would probably be a 7.x-3.x candidate, since I plan on a short cycle for 7.x-2.x.

any progress on this front?

This seems useful: https://drupal.org/project/rest_api_query

As some of you know, we at ThinkShout our beginning work on a new branch of the SF suite based on the REST API. From my research so far, the REST API at this point is more less on par with the SOAP API and would be a much leaner code base.

The first challenge I'm dealing with is authentication using OAUTH2. More or less following this example workflow, I can get things working. But I haven't done extensive work against OAUTH and want to be sure we don't spend too much time recreating the wheel. The Drupal OAUTH module does not yet support OAUTH2 and seems like substantial overkill for what we need besides. The official PHP PECL OAUTH package likewise does not support OAUTH2. The OAUTH website points to this library on GitHub, which seems a viable option. But most of that code is for implementing a provider, and we're just interested in consuming.

UPDATE: Salesforce also offers the ability to use the REST API by passing an session token obtained from the username/password along with client id and secret. Not as slick as using oauth, but would work. See http://www.salesforce.com/us/developer/docs/api_rest/index_Left.htm#Star....

Any thoughts on whether we should just roll our own simple solution or piggyback on a larger project?

See the 7.x-3.x branch. I don't think any of the maintainers have interest to do this for Drupal 6.