title: Best practice for ASP.NET Web API design?
body: <p>I'm currently trying to create a REST'ish web service backend with an ASP.NET Web API, EF5 Code First approach. Looking now for some advice to avoid the maybe most known novice errors.</p>
  
  <p>Whats the best way of modelling the controller structure for a many to many scenario like the following.</p>
  
  <p>Let's say we have blog posts with tags associated to it. A blog post can have many tags, and a tag can be assigned to many blog post. Blog posts and tags each belong to customer. Pretty standard I would say. But my first concern is how to update blog posts by the following (standard?) endpoint design. </p>
  
  <pre><code>GET    - /api/posts/{id} =&gt; Load the post by id
  DELETE - /api/posts/{id} =&gt; Delete the post by id
  
  POST   - /api/posts/     =&gt; Create a new post from the JSON in the body
  PUT    - /api/posts/{id} =&gt; Update the post from the JSON in the body. Tags as well
  </code></pre>
  
  <p>1.) Is it good practice to POST the tags simply in an array <code>[{"name":"tag1"}, {"name":"tag2"}]</code> and let the server find out if the tags are new or already existing for the customer and they just need to be assigned to the to create blog post.</p>
  
  <p>Doing it in two steps (first create the post and then create/assign the tasks) doesn't feel right in the disconnected web world. </p>
  
  <p>2.) More or less the same goes for the update process. Would it be good practice to just PUT the whole object and let the server try to do the update itself?</p>
  
  <p>Currently I have this "basic" scenario implemented with the tool chain mentioned above. But the solution already feels fairly complicated. Especially fiddling and setting the many to many associations by hand makes things more complex than it should I think.</p>
  
  <p>When it now comes to concurrency handling I'm not really convinced that all this is easy to handle in the disconnected scenario when everything comes down from the client and the server needs to find out everything.</p>
  
  <p>So what is the "correct" implementation of this (easy?) scenario from API's point of view? Might it be easier to split up entity creation/update? But then I would ask myself how to tie the distinct requests so that the server could now that 2 or more request belong to 1 creation/update.</p>
  
  <p>Hopefully somebody reads until this point and can follow my wooly thoughts.</p>