>>I see three recommendations to switch to WebApi - we can't all be wrong :-}
>>
>>One suggestion - go for the newer 'Attribute Routing' - it's far more flexible and REST friendly than the older convention based approach.
>>
>>http://www.asp.net/web-api/overview/web-api-routing-and-actions/attribute-routing-in-web-api-2
>
>Go on, just throw in more stuff for me to understand, why don't you? :)
>
>I've got a Web Api example to work! Had to get VS 2013 and update to Web Api 2 to get it to work, but it looks like it works properly, so now I need to see if I can do this to use the business objects I created or if I'll need to create Models and controllers to pull my data out of the database (and post it back after being edited).

A couple of basics:

You will need controllers. The controller is what handles the request, and if you have a working example, you've already created one. You don't need to put your business logic in there. You can have the controller make use of your existing business objects. Your original method from your first post should work just fine.

You already have models in the form of your entities. You may however need to add attributes to your entities to control what gets serialized and what doesn't. See http://www.asp.net/web-api/overview/formats-and-model-binding/json-and-xml-serialization. Or, if that doesn't provide you with the control you want, you may find it easier to create a new model to pass the data into.

Routing determines what method handles the request. Rather than point to a specific page, a route will look something like "{controller}/{action}/{id}". The controller is the class that handles the request. The action is the method in the controller class that is used. The id is the parameter passed to the action method. You can change the name of id, add additional parameters, or leave it off entirely. The name id should match the parameter of your method. Attribute based routing allows you to make a change to the standard route or routes for a single method.

You can also leave off the action part of the route and rely on HTTP verbs (http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods). The verbs you would typically use are GET (requesting data), POST (updating a record), and DELETE (self explanatory). So if your route is "{controller}/{id}", a GET request to http://www.yoursite.com/customer/1 would fetch the data for customer 1, a POST request would update customer 1, and a DELETE request would delete customer 1. The method that handles each type is either determined by prefixing the method name with the HTTP verb, or by putting the appropriate attribute on it. See http://www.asp.net/web-api/overview/web-api-routing-and-actions/routing-in-aspnet-web-api

Putting together your previous code, lets say you moved your RunSheetWS.asmx code into RunSheetWSController.cs. Keeping your method name of GetCustomerByCustomerNumber, you could do any of the following options:
1) Use a route of "{controller}/{customerNumber}". The action name is controlled by the naming convention and uses GetCustomerByCustomerNumber for a GET request. The URL would be http://www.yoursite.com/RunSheetWS/{customerNumber}
2) Use a route of "{controller}/{action}/{customerNumber}". The action name is name of your method GetCustomerByCustomerNumber. The URL would be http://www.yoursite.com/RunSheetWS/GetCustomerByCustomerNumber/{customerNumber}
3) Use attribute routing and create a custom route such as

[Route("customers/bynumber/{customerNumber}")]
public string GetCustomerByCustomerNumber(string customerNumber){ //Code goes here }

The URL would be http://www.yoursite.com/customers/bynumber/{customerNumber}