Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>This is an old question, and I'm sure the service has been written a long time ago, but I wanted to contribute an answer anyway.</p> <p>The RESTful approach would be to define an airport resource, such as this:</p> <pre><code>&lt;airport href="/airports/JFK"&gt; &lt;name&gt;JFK&lt;/name&gt; &lt;city&gt;New York&lt;/city&gt; &lt;country&gt;USA&lt;/country&gt; &lt;continent&gt;North America&lt;/continent&gt; &lt;/airport&gt; </code></pre> <p>Or, if you want to use a browser-compatible microformat:</p> <pre><code>&lt;div class="object airport" href="/airports/JFK"&gt; &lt;ul class="attributes"&gt; &lt;li class="name"&gt;JFK&lt;/li&gt; &lt;li class="city"&gt;New York&lt;/li&gt; &lt;li class="country"&gt;USA&lt;/li&gt; &lt;li class="continent"&gt;North America&lt;/li&gt; &lt;/ul&gt; &lt;/div&gt; </code></pre> <p>This resource would be located at a URI like <code>/airports/JFK</code>, which would be retrieved with a <code>GET</code> method, updated with a <code>PUT</code> method, and deleted with a <code>DELETE</code> method.</p> <p>In a design like this, the URI <code>/airports/</code> would represent a container resource for all of the airports in the database, and URIs like <code>/airports/?city=New+York</code> and <code>/airports/?country=USA</code> would be filters on the container to return a subset of the airports. Both of these would be <code>GET</code> methods, and the resources would contain a list of airport resources as defined above, either in full (since they're small) or with a few useful attributes and the <code>href</code> that points to the full resource for each airport.</p> <p>Finally, adding a new resource could either be a <code>PUT</code> method on the airport's full URI, or a <code>POST</code> method on <code>/airports/</code>. In both cases the body of the request is the airport resource as shown above. The difference between the methods is who gets to decide the final URI for the airport: the client decides for <code>PUT</code> and the service decides for <code>POST</code>. Which one you use depends upon whether or not your clients can reasonably determine the right URI. Usually the service decides because the URIs contain a numeric unique identifier and the service has to choose that.</p> <p>Now of course your original question was about SOAP, not REST. I would go ahead and set up a RESTful design as I've described, then describe my resources as complex types using XSD and a SOAP service with actions that duplicate the <code>GET</code>, <code>PUT</code>, <code>DELETE</code>, and <code>POST</code> operations of the RESTful service. This will give you the RPC equivalent of:</p> <pre><code>class Airport has String name has String city has String country has String continent method void update(name, city, country, continent) method void delete() class AirportList method Airport[] get(opt name, opt city, opt country, opt continent) method void add(name, city, country, continent) </code></pre>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload