Answers.Body: <p>Author of the module here...</p>
  
  <p>Great question. I've forseen a need for this and have over the past few versions been stripping out sql queries and BAO calls when possible and replacing them with api calls. But that work is only around half done. And the low-hanging fruit has been picked. The remaining BAO/DAO calls are mostly still in there because there is no equivalent api.</p>
  
  <p>The reason for this approach is that CiviCRM supports api calls over REST, so once we decoupled Webform-CiviCRM from calling internal Civi functions, it would be theoretically possible to pipe all the api calls over REST (assuming you had a nice fast connection between the two servers).</p>
  
  <p>The only "quick 'n easy" way forward I see would be to install CiviCRM on your host Drupal site just so the internal function calls won't bomb, then swap the <code>wf_civicrm_api</code> function in <code>utils.inc</code> to use REST. That should more-or-less work, depending on your use-case.</p>
  
  <p>The "correct" solution is probably to write a CiviCRM extension, installable on the source site, that provides an api wrapper for all required internal functions, and patch Webform-CiviCRM to use that api instead of direct DAO/BAO calls. This would, in theory, allow you to host CiviCRM on WordPress and integrate with a Drupal webform.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-13T18:21:46.510Z
Answers.Text: Do you think a smaller project as I outlined would be feasible? I.e. a stripped down version of webform civicrm that could be installed without CiviCRM on a remote site that accesses CiviCRM entirely by REST? The key question is - are there any non-api CiviCRM access points that are essential? Or are the points where you need BAO/whatever calls the exception for some of the more complicated stuff? At this point, I just need a fairly simple integration to do CRUD functions on contacts. So, a webform civicrm "lite".
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-14T01:01:52.730Z
Answers.Text: Grepping for `CRM_*` in the code brings up 100+ uses, from accessing constants to making database queries.
  So is it possible to write a remote version of the module? Yes, but it would probably be a 50 hr project to get a "lite" version up and running.
Answers.UserDisplayName: Coleman
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-10T21:29:53.177Z
Answers.LastActivityDate: 2017-03-10T21:29:53.177Z
Answers.UserDisplayName: Coleman
Answers.Body: <p>you may want to have a look at <a href="https://github.com/CiviMRF/documentation" rel="nofollow noreferrer">CiviMcRestFace</a> (yes, that's really the name...). The project aims at providing an infrastructure for the data exchange between a public facing website with a CiviCRM system. It i still in a preliminary phase but feel free to get in contact with Erik Hommel or Björn Endres.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-13T18:18:16.200Z
Answers.Text: That looks more aspirational that actual, yes? I didn't really want to get that abstracted and lost in a bigger project.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-14T07:26:22.287Z
Answers.Text: Well it's definitely not "plug and play" but it's base has been used in at least one (webform) project (https://github.com/systopia/ica_event_cmrf_connector). Also if you are likely to invest a lot of time to connect your external page it may be worth contributing to the project in order to enhance maintainability as well as re-usability.
Answers.UserDisplayName: Fabian
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-15T18:44:11.507Z
Answers.Text: Ah, I see now, thanks, that does look like a worthwhile approach for this problem.
Answers.UserDisplayName: Alan Dixon
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-13T08:13:00.713Z
Answers.LastActivityDate: 2017-03-13T08:13:00.713Z
Answers.UserDisplayName: Fabian
Body: <p>I'd like to integrate a Drupal webform on a non-CiviCRM install with a Drupal CiviCRM install on a separate server. It seems to me that using a stripped down kind of module like webform-civicrm using a REST interface with CiviCRM might be a feasible option, stripping out some of the more complex integrations that require any native Civi code.</p>
  
  <p>Has anyone tried something like this?</p>
  
Tags: <webform-civicrm>
Title: Webform CiviCRM integration with REST
ThreadText: # Webform CiviCRM integration with REST
  
  (Asked by: username_0 on 2017-03-10)
  
  I'd like to integrate a Drupal webform on a non-CiviCRM install with a Drupal CiviCRM install on a separate server. It seems to me that using a stripped down kind of module like webform-civicrm using a REST interface with CiviCRM might be a feasible option, stripping out some of the more complex integrations that require any native Civi code.
  
  Has anyone tried something like this?
  
  **Tags:** webform-civicrm
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2017-03-10. Score: 2 | Accepted answer
  
  Author of the module here...
  
  Great question. I've forseen a need for this and have over the past few versions been stripping out sql queries and BAO calls when possible and replacing them with api calls. But that work is only around half done. And the low-hanging fruit has been picked. The remaining BAO/DAO calls are mostly still in there because there is no equivalent api.
  
  The reason for this approach is that CiviCRM supports api calls over REST, so once we decoupled Webform-CiviCRM from calling internal Civi functions, it would be theoretically possible to pipe all the api calls over REST (assuming you had a nice fast connection between the two servers).
  
  The only "quick 'n easy" way forward I see would be to install CiviCRM on your host Drupal site just so the internal function calls won't bomb, then swap the `wf_civicrm_api` function in `utils.inc` to use REST. That should more-or-less work, depending on your use-case.
  
  The "correct" solution is probably to write a CiviCRM extension, installable on the source site, that provides an api wrapper for all required internal functions, and patch Webform-CiviCRM to use that api instead of direct DAO/BAO calls. This would, in theory, allow you to host CiviCRM on WordPress and integrate with a Drupal webform.
  
  > **Comments:**
  > **username_0**: Do you think a smaller project as I outlined would be feasible? I.e. a stripped down version of webform civicrm that could be installed without CiviCRM on a remote site that accesses CiviCRM entirely by REST? The key question is - are there any non-api CiviCRM access points that are essential? Or are the points where you need BAO/whatever calls the exception for some of the more complicated stuff? At this point, I just need a fairly simple integration to do CRUD functions on contacts. So, a webform civicrm "lite".  
  > **username_1**: Grepping for `CRM_*` in the code brings up 100+ uses, from accessing constants to making database queries. So is it possible to write a remote version of the module? Yes, but it would probably be a 50 hr project to get a "lite" version up and running.  
  
  ---
  
  ### Answer by username_2 on 2017-03-13. Score: 2
  
  you may want to have a look at [CiviMcRestFace](https://github.com/CiviMRF/documentation) (yes, that's really the name...). The project aims at providing an infrastructure for the data exchange between a public facing website with a CiviCRM system. It i still in a preliminary phase but feel free to get in contact with Erik Hommel or Björn Endres.
  
  > **Comments:**
  > **username_0**: That looks more aspirational that actual, yes? I didn't really want to get that abstracted and lost in a bigger project.  
  > **username_2**: Well it's definitely not "plug and play" but it's base has been used in at least one (webform) project (https://github.com/systopia/ica_event_cmrf_connector). Also if you are likely to invest a lot of time to connect your external page it may be worth contributing to the project in order to enhance maintainability as well as re-usability.  
  > **username_0**: Ah, I see now, thanks, that does look like a worthwhile approach for this problem.  
  
  ---
  
  