Answers.Body: <p>I don't have a proper answer to the question of how to use <code>SoapServer</code>, but it may be useful to place that in context.</p>
  
  <p>The <code>extern/soap.php</code> script is a bit of a relic which is not on par with the RESTy APIv3. I was just a casual user at the time, but I'm pretty sure it predates APIv3 and (probably) APIv2. Its major use-case was facilitating a fast return-channel for CiviMail. (There's some kind of smtpd/perl/soap integration which folks used to use.) IMHO, the only reason to retain it in the codebase is for backward compatibility (on the off-chance that it maybe still works for existing installations).</p>
  
  <p>If you skim the code of <a href="https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/SoapServer.php" rel="nofollow"><code>CRM_Utils_SoapServer</code></a>, you'll see <code>get_contact()</code> and a bunch of mail-related actions (and basically nothing else). The design is generally... shallow.</p>
  
  <p>If you really do need SOAP access, then I'd recommend implementing new bindings between SOAP and APIv3. Ideally:</p>
  
  <ul>
  <li>The SOAP implementation should be generic, passing along requests to <code>civicrm_api3()</code> and getting metadata from <code>civicrm_api3</code> (ie <code>Entity.get</code> and <code>*.getfields</code>).</li>
  <li>The SOAP end-point should ideally go through the menu/router system -- rather than a standalone script (e.g. <code>http://example.com/civicrm/soap</code> instead of <code>http://example.com/sites/something/modules/civicrm/extern/soap.php</code>).</li>
  <li>The SOAP end-point should ideally go into an extension. </li>
  </ul>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-11T13:20:06.817Z
Answers.Text: Thanks for the detailed description. Now, I get a proper idea of my findings related to this:)
Answers.UserDisplayName: jitendra - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-11T07:47:01.110Z
Answers.LastActivityDate: 2015-08-11T07:47:01.110Z
Answers.UserDisplayName: Tim Otten
Body: <p>As I can see there is a get_contact() function in CRM/Utils/SoapServer.php.
  I would like to use this function to get the list of contact. How can I do that ? Is it similar to how we make a Rest api call like <code>http://&lt;site_name&gt;/sites/all/modules/civicrm/extern/soap.php?</code> ? If it is, what params do I need to pass to get the required result ?</p>
  
  <p>Any help/hints would be appreciated. Thanks.</p>
  
  <p>Update : I'm using the latest version of CiviCRM.</p>
  
Tags: <api><civicrm-home><soap>
Title: How do I make a Simple SOAP request in CiviCRM?
ThreadText: # How do I make a Simple SOAP request in CiviCRM?
  
  (Asked by: username_0 on 2015-08-11)
  
  As I can see there is a get\_contact() function in CRM/Utils/SoapServer.php.
  I would like to use this function to get the list of contact. How can I do that ? Is it similar to how we make a Rest api call like `http:///sites/all/modules/civicrm/extern/soap.php?` ? If it is, what params do I need to pass to get the required result ?
  
  Any help/hints would be appreciated. Thanks.
  
  Update : I'm using the latest version of CiviCRM.
  
  **Tags:** api, civicrm-home, soap
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-08-11. Score: 2
  
  I don't have a proper answer to the question of how to use `SoapServer`, but it may be useful to place that in context.
  
  The `extern/soap.php` script is a bit of a relic which is not on par with the RESTy APIv3. I was just a casual user at the time, but I'm pretty sure it predates APIv3 and (probably) APIv2. Its major use-case was facilitating a fast return-channel for CiviMail. (There's some kind of smtpd/perl/soap integration which folks used to use.) IMHO, the only reason to retain it in the codebase is for backward compatibility (on the off-chance that it maybe still works for existing installations).
  
  If you skim the code of [`CRM_Utils_SoapServer`](https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/SoapServer.php), you'll see `get_contact()` and a bunch of mail-related actions (and basically nothing else). The design is generally... shallow.
  
  If you really do need SOAP access, then I'd recommend implementing new bindings between SOAP and APIv3. Ideally:
  
  * The SOAP implementation should be generic, passing along requests to `civicrm_api3()` and getting metadata from `civicrm_api3` (ie `Entity.get` and `*.getfields`).
  * The SOAP end-point should ideally go through the menu/router system -- rather than a standalone script (e.g. `http://example.com/civicrm/soap` instead of `http://example.com/sites/something/modules/civicrm/extern/soap.php`).
  * The SOAP end-point should ideally go into an extension.
  
  > **Comments:**
  > **username_0**: Thanks for the detailed description. Now, I get a proper idea of my findings related to this:)  
  
  ---
  
  