LM Tech's blog

Software Architecture & Design Patterns

In this post we see how to consume the RESTful service described in the post Design a RESTful service with .NET framework 4.0 using the Ajax functionality provided by jQuery.

jQuery includes some utilities to simplify the Ajax call. In our example we will use the jQuery.ajax() function to do them. jQuery.ajax() accepts just a single argument: an options object whose properties specify many details about how to perform the Ajax request.


jQuery.ajax({
    type: "GET|POST|DELETE|PUT",
    url: url,
    data: data,
    dataType:"text|html|json|jsonp|script|xml"
    success: success_callback,
    error: error_callback
});

More...



In the post Design a RESTful service with .NET framework 4.0 i've shown how to create a RESTful service using .Net Framework 4.0.

Let's see now how to consume the service through a .Net client application. We will use the WebClient class defined in the System.Net namespace for sending and receiving data to or from the RESTful service, and the DataContractJsonSerializer class to serialize and deserialize an instance of a type to or from a JSON document. More...



This post shows how to implement a RESTful service using .NET framework 4.0.

Using the REST terminology, we will call "resource" any object, identified in an unique way by an URI, on which to invoke one of the "request methods" ADD, PUT, DELETE, GET.

In our example the resource is represented by the "Contact" object defined as follow:

public class Contact
{
     public int ContactId { get; set; }
     public string fName { get; set; }
     public string lName { get; set; }
     public string eMail { get; set; }
}

Implement a RESTful service in .NET 4.0 is simple as to write a wcf service. Infact .Net 4.0 provides a very simple REST programming model thanks to the WebInvoke/WebGet attributes.
Is sufficient decorate the service operation with one of these attributes and it can be called by the WCF REST programming model.

The WebInvoke attribute exposes some properties through which you can specify the REST options:

Method: Gets and sets the protocol (for example HTTP) method the service operation responds to (ADD, PUT, DELETE, GET)

RequestFormat: determines the format of requests made to a service operation. The possible values are Xml and Json.

ResponseFormat: determines the format of responses sent from a service operation. The possible values are Xml and Json.

UriTemplate: determines which requests get dispatched to which service operations.

You can also use the WebInvoke attribute insted of the WebGet attribute specifying Method = "GET".

Here an example of service contract:

[ServiceContract]
public interface IContacts
{
    [OperationContract]
    [WebInvoke(Method = "ADD",
         ResponseFormat = WebMessageFormat.Json,
         RequestFormat = WebMessageFormat.Json, UriTemplate = "Add")]
    Contact Add(Contact contact);

    [OperationContract]
    [WebInvoke(Method = "DELETE",
        ResponseFormat = WebMessageFormat.Json, UriTemplate = "Delete")]
    void Delete(string id);

    [OperationContract]
    [WebInvoke(Method = "PUT",
        ResponseFormat = WebMessageFormat.Json)]
    void Update(Contact contact);

    [OperationContract]
    [WebInvoke(Method = "GET",
        ResponseFormat = WebMessageFormat.Json)]
     List<Contact> GetAll();

    [OperationContract]
    [WebInvoke(Method = "GET",
        ResponseFormat = WebMessageFormat.Json, UriTemplate = "GetContact/{id}")]
    Contact GetContact(string id);
}

In a typical scenario, the service contract IContacts could be implemented by the Contacts.svc service, hosted at the address http://myserver/contactservice/Contacts.svc.

In this scanario the service operations can be invoked in the following way:

http://myserver/contactservice/Contacts.svc/Add
http://myserver/contactservice/Contacts.svc/Update
http://myserver/contactservice/Contacts.svc/GetContact/123
http://myserver/contactservice/Contacts.svc/Delete
http://myserver/contactservice/Contacts.svc/GetAll



Feb
02

RESTful Web Service

by lma | Tags:

A RESTful Web Service is a web service that implemed the REST architectural style.

The RESTful web API defines a set of standards to interact with resources on the web:

URI (Uniform Resource Identifier)

Identifies in a unique way a resource on the web (ex. http://mysite.com/resources/resource_name ).

MIME Type

Internet Media Type of the data (ex. XML, HTML, JSON).

HTTP Methods (request methods)

Standard methods that can be applied to the specified resource:

GET (requests a specific representation of a resource)
PUT (create or update a resource with the supplied representation)
DELETE (deletes the specified resource)
POST (submits data to be processed by the identified resource)



Representational State Transfer (REST) is a style of software architecture for distributed systems such as the World Wide Web. REST is based on Resources that are identified by a unique URI.
REST is not tied to any particular technology or platform - it’s simply a way to design things to work like the Web. People often refer to services that follow this philosophy as "RESTful services".

The REST architectural style is based on the following constraints:

Client-server
A uniform interface separates clients from servers, so we can speak of "separation-of-concerns". Servers are not concerned with the user interface, so that servers can be simpler and more scalable. Servers and clients are loosely coupled and may also be replaced and developed independently, as long as the interface between them is not altered.

Stateless
Each request to the server should contain all the information required to understand and complete the request.

Cacheable
 As on the World Wide Web, clients can cache responses to improve the performance and reduce network traffic.

Layered system
A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers like Proxy servers or Cache servers can be used to improve performance or introduce security.

Uniform interface
The uniform interface between clients and servers simplifies and decouples the architecture, which enables each part to evolve independently. HTTP defines a standard set of methods (request methods), status codes, and headers for interacting with resources on the Web.

Common request methods are:

GET (requests a specific representation of a resource)
PUT (create or update a resource with the supplied representation)
DELETE (deletes the specified resource)
POST (submits data to be processed by the identified resource)



One of the most relevant issue in software architecture is how to separate the implementation of cross-cutting concerns from the implementation of the core-concerns.
A cross-cutting concern is a concern that affects multiple components in a system, such as logging, security, and exception handling.
Microsoft's Unity Application Block (Unity for short), that is part of the Microsoft Enterprise Library 5.0, enable you to effectively capture calls to objects and add additional functionality to the target object. More...



The factory design pattern is a creational pattern that favor the abstraction of the objects creation's process.
The creation of an object can be a complex process where many properties must be setted and other nested objects must be created.
To reduce the code duplication and the coupling between classes, is better to put the creation code in a unique place (the factory), where you can access to get the instance of the objects.
A "factory" therefore, is an object for creating other objects. More...



Another way to implement the Inversion of Control (IoC) principle, in addition to the Dependency Injection, is the plug-in design pattern.

The pattern consists in to load an assembly that implements a common interface at runtime. In this way, a class that depends from an object in an other assemby is completely decoupled from it, or rather, it has no reference to dependent assembly. More...



In the observer design pattern an object (the observable) mantain a list of its dependents (the observers) and notifies them when its state changes by calling a method on each registered subscribers. More...



The Separated Interface pattern addresses the problem of separating the interface that describes the functionalities from its implementation. The pattern prescribes that you use different packages (assemblies in the .NET Framework) for the interface and any of its implementations. The packages that need to consume the functionalities know only the definition of the interface and are completely unaware of the implementation. More...