CODEWITHSUNDEEP
asp.netweb-servicesapi
Gorge Benson
Gorge Benson

Reputation: 43

Best Way to Write an Asp.Net Web Service To Play Well In the Wild

I am writing an API for my ASP.NET application that other developers will use. The API will basically return a list of people with their first name, last name, and id. There are lots of ways to write web services in ASP.NET, the easiest probably being create a web service function (asmx) that returns a DataTable. This is simple enough for other .NET developers to deal with, but I am not convinced that this is the best way to write a web service for general platform and language independence.

What is the currently accepted standard to write a web service like this that plays well in the wild today?

Upvotes: 1

Views: 399

Answers (2)

tuncalik
tuncalik

Reputation: 1144

I am currently working on a similar issue: A web api service in .NET that receives data tables as input parameters, apply some operations on them (using Table Valued Functions), and return some output data tables.

In your case, you don't need to use a complex class like DataTable; you could use an array (List<>) of a simple class with fields like first name, last name and id. Using Web Api of ASP.NET you could do something like the following:

1) Create a new WebApi project in Visual Studio: For example (in VS 2012) C# > Web > ASP.NET MVC 4 Web Application > select "Wep Api" as project template

You will see a VS project with lots of folders, including one named Models

For help see: http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api/tutorial-your-first-web-api

2) Create a new model code file Person.cs with a class like the following:

public class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string[] Friends { get; set; }
}

3) Create e new controller code file PersonController.cs with methods for getting, inserting and updating records of the database. All the necessary serialization/deserialization (JSON and XML) and data binding is done automatically by the Web Api environment set by the project template.

    // Get all the records of persons
    public IList<Person> Get()
    {
        // read database into a list of persons (List<Person>)
        // return List<Person>
    }

Return record of a selected person:

   public Person Get(int id)
   {
        // read database for a selected person
   }

Parameter binding (reading a JSON/XML content sent by http POST into an object, or into a list objects) is also done automatically, as easy as the following:

    // parameter binding: Create a Person object with content from XML/JSON 
    public void ReadPerson(Person p)
    {
       Trace.WriteLine(Person.Id);
    }


    public void ReadPersonList(List<Person> plist)
    {
       Trace.WriteLine(plist.Count);
    }

Upvotes: 0

mellamokb
mellamokb

Reputation: 56779

Some ideas that come to mind from experience:

  1. Use WCF, not .asmx. WCF does all the same things that ASMX files do, and is generally the replacement for ASMX services (see here and here).
  2. Write methods using simple POCO data types, like List<Person> rather than DataTable. Basic types serialize more easily and will make more sense in other programming environments since you want your service to be language independent.
  3. Provide generic CRUD methods for managing data. Depending on how your service will be consumed, if the user needs to modify data, a simple method is to provide getBlah(), updateBlah(obj newObj), deleteBlah(obj objToDelete), etc. that use the same data types.
  4. Hide the details that the service consumer doesn't need to know, rather than just blindly exposing all of your data types, structures, and field names as-is. This will make your service more robust for handling internal changes, and you can simplify and control what the end-users see. For instance, if you have a Person class with 30 properties, and only 5 are relevant to the end-user, provide a class that interfaces between Person and a PersonSimple class which is exposed. Without this layer, your end-users will have to modify your code every time you change your data structure, and you will be locked down by this tight coupling.

If security is important

  1. Execute your service over SSL. This protects data transfered over the wire from being sniffed.
  2. Use authentication, either with a Login method and session, or SOAP headers. Services by default are anonymous unless there is some sort of authentication scheme. Even if you think nobody will find your service because you only provide the URL to your users, it will get out somehow, somewhere, and people will try to misuse the service when it does. Plus, you can control who can do what by different logins and authorization schemes.

Upvotes: 3

Related Questions