title: Rest API and DDD
body: <p>In my project using DDD methodology.</p>
  
  <p>The project has the aggregate(entity) Deal. This aggregate has many of use cases.</p>
  
  <p>For this aggregate I need to create a rest api.</p>
  
  <p>With standard: create and delete no problem.</p>
  
  <p>1) <strong>CreateDealUseCase</strong>(name, price and many another params);</p>
  
  <pre><code>POST /rest/{version}/deals/
  { 
     'name': 'deal123',
     'price': 1234;
     'etc': 'etc'
  }
  </code></pre>
  
  <p>2) <strong>DeleteDealUseCase</strong>(id)</p>
  
  <pre><code>DELETE /rest/{version}/deals/{id}
  </code></pre>
  
  <p>But what to do with the rest of the use cases?</p>
  
  <ul>
  <li>HoldDealUseCase(id, reason);</li>
  <li>UnholdDealUseCase(id);</li>
  <li>CompleteDealUseCase(id, and many another params);</li>
  <li>CancelDealUseCase(id, amercement, reason);</li>
  <li>ChangePriceUseCase(id, newPrice, reason);</li>
  <li>ChangeCompletionDateUseCase(id, newDate, amercement, whyChanged);</li>
  <li>etc(total 20 use cases)...</li>
  </ul>
  
  <p>What are the solutions?</p>
  
  <p>1) <strong>Use verbs</strong>:</p>
  
  <pre><code>PUT /rest/{version}/deals/{id}/hold
  { 
     'reason': 'test'
  }
  </code></pre>
  
  <p>But! Verbs can not be used in the url(in REST theory).</p>
  
  <p>2) <strong>Use the completed state</strong>(which will be after the the use case):</p>
  
  <pre><code>PUT /rest/{version}/deals/{id}/holded
  { 
     'reason': 'test'
  }
  </code></pre>
  
  <p>Personally for me it looks ugly. Maybe I'm wrong?</p>
  
  <p>3) <strong>Use 1 PUT request for all operations:</strong></p>
  
  <pre><code>PUT /rest/{version}/deals/{id}
  { 
     'action': 'HoldDeal',
     'params': {'reason': 'test'}
  }
  
  PUT /rest/{version}/deals/{id}
  { 
     'action': 'UnholdDeal',
     'params': {}
  }
  </code></pre>
  
  <p>It is difficult to handle in the backend.
  Moreover, it is difficult to document. Since 1 action has many different variants of requests, from which is already dependent on specific responses.</p>
  
  <p>All solutions have significant drawbacks.</p>
  
  <p>I have read many articles about the REST on the internet. Everywhere only a theory, how to be here with my specific problem?</p>