1. Introduction

Cuubez|Rest is a project that enables development and consumption of REST style web services. The core server runtime is based on the unique way to the Cuubez . The project also introduces a client runtime which can leverage certain components of the server-side runtime. Cuubez|Rest will deliver component technology that can be easily integrated into a variety of environments. Simplicity is the major strength of the Cuubez|Rest.

2. REST Architecture

For a detailed understanding of the REST architecture refer to the description by Roy Fielding in his dissertation, The Design of Network-based Software Architectures. In particular, Chapter 5 Representational State Transfer (REST) describes the principles of the architecture.

Figure 1: REST architecture

Figure 1 demonstrates the design principles and components that comprise a REST web service. Cuubez reflects these design principles in the implementation of web services.

3. JAX-RS Compliancy

Cuubez 1.0 is a partial implementation of the JAX-RS v2.0 specification. JAX-RS is a Java based API for RESTful Web Services is a Java programming language API that provides support in creating web services according to the Representational State Transfer (REST) architectural style. JAX-RS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints.

4. Framework Architecture

TBD

5. Cuubez Server

Cuubez server module is a partial implementation of the JAX-RS v 2.0 . Remaining features will release with future release. Majority of most required features released with server 1.0 release.

5.1 Configuration

The ContextLoaderListner? context listener has to be deployed in order to create the registry for cuubez ,while the ServiceInitiator? servlet is used so that incoming requests are correctly routed to the appropriate services. We have configured the specific servlet, named “cuubez”, to intercept requests under the “/rest/” path.

Note that the value does not containing the trailing slash nor the wildcard.

The addAddress method defaults to the MIME type of the @Consume annotation at the class level. The createUser method's @Consume annotation overrides the class-level @Consume setting, and specifies that the method can produce JSON rather than XML.More than one media type may be declared in the same @Consumes declaration, for example:

5.3 Resource Matching

Normal URI Matching

Imagine that you have a school-like database structure that has members, and members can be students and teachers. You want to make an REST API that will return a list of all members and then specifically the list of students and the list of teachers. Let’s see how you could do that:

@Path("/members")
@Produces(MediaType.APPLICATION_JSON)
public class School{
@GET
public Response getMember() {
Member output = new Member("This is the list of our members:");
// . . . work to retrieve the list of members
return Response.ok().entity(output).build();
}
@GET
@Path("/teachers")
public Response getTeachers() {
Teacher output = new Teacher("This is the list of our teachers:");
// . . . work to retrieve the list of teachers
return Response.ok().entity(output).build();
}
@GET
@Path("/students")
public Response getStudents() {
Student output = new Student("This is the list of our students:");
// . . . work to retrieve the list of students
return Response.ok().entity(output).build();
}
}

When you put on your browser:

http://localhost:8080/school-info/rest/members

Outputs:

{"description":"This is the list of our members:"}

http://localhost:8080/school-info/rest/members/students

Outputs:

{"description":"This is the list of our students:"}

http://localhost:8080/school-info/rest/members/teachers

Outputs:

{"description":"This is the list of our teachers:"}

Parameterized URI Matching

This works similarly to the normal URI matching, except this enables user input and the form of the URI is not restricted to /students or/members. The user can put any form of URI he wants. Then the method can parse that URI and act accordingly. For example let’s say we want to list all information available about a member and the client has to provide just a username:

As you can see we define a Path Parameter using /{ parameter_name } syntax ( you can also just put { parameter_name } without the /). The Path Parameter can be parsed using @PathParam? annotation, on the argument of getMemberInfo method. If parsed correctly, the value of the Path Parameter will be available to the method through the String username variable.

When you put on your browser:

http://localhost:8080/school-info/rest/members/james

Outputs:

{"description":"This is all the info on : james"}

http://localhost:8080/school-info/rest/members/lisa

Outputs:

{"description":"This is all the info on : lisa"}

Regular Expression URI Matching

Cuubez server 1.0 release is not support to regular expression URI matching

6.Security

6.1 Basic HTTP Authentication

Basic HTTP authentication solve following security problems.

Get username and password from http request

Fetch the applicable method security details

Verify if user is authorized to access the API

Return valid error codes in case of invalid access

These basic security problems are solving by using set of annotations and Authentication filter implementation.

interceptorRequestContext parameter provides access to method which will be invoked as a result of calling the REST API. request parameter provides access to request headers and parameters passed by client.

7.1.4 Step 4: Create your first RESTful service

In a REST based architecture everything is a resource. A resource is accessed via a common interface based on the HTTP standard methods (e.g., POST, GET, PUT or DELETE). Every resource should support the HTTP common operations. Resources are identified by global ID's (which are typically URIs). In the first example, we will recall a RESTful Web service which returns a User object when a certain path is request with an HTTP GET: