title: Advice moving asp web forms / asmx web service application to MVC / Web API
body: <p>I am looking to update / refresh an aging application as it has become unwieldy over time.</p>
  
  <p>The application tracks prescriptions through the dispensing process in a pharmacy. The dispensing process contains a number of 'activities' that are recorded using barcode scanners.</p>
  
  <p>The application is currently an asp.net web forms application for the main UI,  with an asp.net asmx service providing methods to process the barcode scans. (Barcode scanning client app is a .NET windows forms app)</p>
  
  <p>The web service (an asmx file which is the same IIS website as the main UI) maintains collections of 'live' prescriptions/users/activities in the application object to minimise database access.</p>
  
  <p>I am drawn to the MVC model for the main web UI as this provides a great separation of concerns, allows us to provide views for mobile devices etc. </p>
  
  <p>Where I am a little uncertain is whether the web service should move to become a RESTful web api service. This would obviously have implications on the design of the MVC application. The present set-up has the service doing a lot of the work - i.e. we have a main method of 'process scan' that encapsulates all the logic in what to do with the scan, e.g:</p>
  
  <p>-User Barcode scanned - service holds this against a device ID (device ID passed to method)</p>
  
  <p>-Prescription Barcode Scanned - service checks that there is a User Barcode for this device ID, stores Prescription ID if true)</p>
  
  <p>-Activity Barcode scanned - service checks user/prescription are complete then checks user is able to record that activity, if the activity is correct, is the right activity in a scanning sequence, if OK records the activity then checks if the users previous activity needs to be finished etc. etc.</p>
  
  <p>Moving to a RESTful implementation would seem to suggest this is split out to have the following endpoints:</p>
  
  <p>GET webservice/Users/USERID</p>
  
  <p>GET webservice/Prescriptions/PRESID</p>
  
  <p>POST webservice/Activities/ACTIVITYID</p>
  
  <p>This is where I start loosing the plot - This seems to be making things more complicated and the POST part confuses me. All the examples given are nice clear cases where you are updating one resource (e.g. an order or customer). In this case the addition of an activity using POST can have an impact on other activities and prescriptions. Should I then be making the calls less tightly coupled: i.e. the request should return the ID's of activities / prescriptions that need updating &amp; then I call additional POST / PUT calls in to update them? Aren't we simply moving the logic to the client....</p>
  
  <p>Am I missing the point here, should I just dive in to the web api bit and develop the rest out from there....any advice from people who have already done this would be great!</p>
  
  <p>Thanks</p>