Rest – Possible to create REST web service with ASP.NET 2.0

restweb services

Is it possible to create a REST web service using ASP.NET 2.0? The articles and blog entries I am finding all seem to indicate that ASP.NET 3.5 with WCF is required to create REST web services with ASP.NET.

If it is possible to create REST web services in ASP.NET 2.0 can you provide an example.

Thanks!

Best Answer

I have actually created a REST web service with asp.net 2.0. Its really no different than creating a web page.

When I did it, I really didn't have much time to research how to do it with an asmx file so I did it in a standard aspx file. I know thier is extra overhead by doing it this way but as a first revision it was fine.

protected void PageLoad(object sender, EventArgs e)
{
    using (XmlWriter xm = XmlWriter.Create(Response.OutputStream, GetXmlSettings()))
    {
        //do your stuff
        xm.Flush();
    }
}

    /// <summary>
    /// Create Xml Settings object to properly format the output of the xml doc.
    /// </summary>
    private static XmlWriterSettings GetXmlSettings()
    {
        XmlWriterSettings xmlSettings = new XmlWriterSettings();
        xmlSettings.Indent = true;
        xmlSettings.IndentChars = " ";
        return xmlSettings;
    }

That should be enough to get you started, I will try and post more later.

Also if you need basic authentication for your web service it can be done, but it needs to be done manually if you aren't using active directory.

Related Solutions

C# – REST from asp.net 2.0

If your looking for a project that templates a REST service, you're correct in saying there is no out of the box solution. However, RESTful web services are possible using WCF. The key part is to use several attributes when defining your service functions that let the .NET framework know that the function is not expecting SOAP. The main attribute to use is the WebInvoke attribute.

Here is an example from developer.com:

[OperationContract]
[WebInvoke(Method = "PUT", UriTemplate = "/admin/post/{id}")]
void UpdatePost(string id, Post post);

The above code will actually be defined in an interface for your web service. The interface is created automatically when you create your WCF web service project. The actual code for the function will be placed in the class used to implement the web service.

Check out the article on developer.com for a full tutorial. It might seem overwhelming at first if your new to WCF, but after you dive into it, I'm sure you'll start to pick things up quickly. Here is the link for the artile: http://www.developer.com/net/article.php/10916_3695436_1

To answer all of your questions,

a) In .NET 2.0 you should be able to build RESTful services using WSE2.0, but if you have the option to use .NET 3.5, I would strongly recommend going the route of WCF since it is much easier and is designed with REST in mind.

b) Converting your project won't be hard at all. It's just a matter of targetting the new version of the framework in your project settings. Converting a web service from a WSE2.0 service to a WCF service will be a bit trickier though. The easiest way to do so would be to copy the code from each of the different web service functions into the class where you implement the new version of the function. Copy-Paste shinanigans :)

c) I'm not sure what this starter kit is that you're referring to. RESTful web services should be fully supported in WCF which was fully released as of 3.5

d) It would be helpful to understand WCF at least a little before beginning, but it's not crutial to understand it completely in order to get started. I would recommend just reading through the MSDN article on WCF at least once, and then begin working. I'm sure you will come across other questions as you begin, but you can look up those parts as you come across them.

Anyway, I hope this information helps. Good luck to you.

Edit

Some improvements have been made in the REST world. As Darrel Miller mentioned in the comments, WCF was not in fact built with REST in mind. I mis-spoke previously. In fact the framework is built with SOAP in mind and the WebInvoke attribute fills the gap. Although there is a lot of debate around the topic (Web API vs WCF REST), ASP.NET Web API is a new option for building REST services in .NET. I would strongly recommend that anyone who reads this post and is able to use .NET 4.5 in their project look into it as an option.

Rest – Understanding REST: Verbs, error codes, and authentication

I noticed this question a couple of days late, but I feel that I can add some insight. I hope this can be helpful towards your RESTful venture.

Point 1: Am I understanding it right?

You understood right. That is a correct representation of a RESTful architecture. You may find the following matrix from Wikipedia very helpful in defining your nouns and verbs:

When dealing with a Collection URI like: http://example.com/resources/

GET: List the members of the collection, complete with their member URIs for further navigation. For example, list all the cars for sale.
PUT: Meaning defined as "replace the entire collection with another collection".
POST: Create a new entry in the collection where the ID is assigned automatically by the collection. The ID created is usually included as part of the data returned by this operation.
DELETE: Meaning defined as "delete the entire collection".

When dealing with a Member URI like: http://example.com/resources/7HOU57Y

GET: Retrieve a representation of the addressed member of the collection expressed in an appropriate MIME type.
PUT: Update the addressed member of the collection or create it with the specified ID.
POST: Treats the addressed member as a collection in its own right and creates a new subordinate of it.
DELETE: Delete the addressed member of the collection.

Point 2: I need more verbs

In general, when you think you need more verbs, it may actually mean that your resources need to be re-identified. Remember that in REST you are always acting on a resource, or on a collection of resources. What you choose as the resource is quite important for your API definition.

Activate/Deactivate Login: If you are creating a new session, then you may want to consider "the session" as the resource. To create a new session, use POST to http://example.com/sessions/ with the credentials in the body. To expire it use PUT or a DELETE (maybe depending on whether you intend to keep a session history) to http://example.com/sessions/SESSION_ID.

Change Password: This time the resource is "the user". You would need a PUT to http://example.com/users/USER_ID with the old and new passwords in the body. You are acting on "the user" resource, and a change password is simply an update request. It's quite similar to the UPDATE statement in a relational database.

My instinct would be to do a GET call to a URL like /api/users/1/activate_login

This goes against a very core REST principle: The correct usage of HTTP verbs. Any GET request should never leave any side effect.

For example, a GET request should never create a session on the database, return a cookie with a new Session ID, or leave any residue on the server. The GET verb is like the SELECT statement in a database engine. Remember that the response to any request with the GET verb should be cache-able when requested with the same parameters, just like when you request a static web page.

Point 3: How to return error messages and codes

Consider the 4xx or 5xx HTTP status codes as error categories. You can elaborate the error in the body.

Failed to Connect to Database: / Incorrect Database Login: In general you should use a 500 error for these types of errors. This is a server-side error. The client did nothing wrong. 500 errors are normally considered "retryable". i.e. the client can retry the same exact request, and expect it to succeed once the server's troubles are resolved. Specify the details in the body, so that the client will be able to provide some context to us humans.

The other category of errors would be the 4xx family, which in general indicate that the client did something wrong. In particular, this category of errors normally indicate to the client that there is no need to retry the request as it is, because it will continue to fail permanently. i.e. the client needs to change something before retrying this request. For example, "Resource not found" (HTTP 404) or "Malformed Request" (HTTP 400) errors would fall in this category.

Point 4: How to do authentication

As pointed out in point 1, instead of authenticating a user, you may want to think about creating a session. You will be returned a new "Session ID", along with the appropriate HTTP status code (200: Access Granted or 403: Access Denied).

You will then be asking your RESTful server: "Can you GET me the resource for this Session ID?".

There is no authenticated mode - REST is stateless: You create a session, you ask the server to give you resources using this Session ID as a parameter, and on logout you drop or expire the session.

Best Answer

Related Solutions

C# – REST from asp.net 2.0

Rest – Understanding REST: Verbs, error codes, and authentication

Related Topic