RESTful Web Services

                                                            RESTful Web services

Compare and contrast Message oriented communication with resource oriented communication

Message Oriented Communication	Resource Oriented Communication
Persistence and synchronicity	Data stream
Message-oriented transient communication • Berkeley socket • MPI	Quality of services
Message-oriented persistent communication	Stream synchronization

Discuss the resource based nature of the REST style

·         Things vs. Actions

·         Nouns vs. Verbs

·         Identified by URIs

·         Multiple URIs may refers to same resource

·         But different according to the HTTP verb used (as like CRUD operation on same student resource)

·         Separate from their representations

·        Resource may be represented as request content type either JSON or XML etc.

Explain the meaning of “representations” in REST style

Resource Data :

Resources have data associated with them. The richness of data that can be associated with a resource is part of the resource model for an API. It denes for example the available data types and their behavior.

Based on my experience, I have developed a strong conviction that the JSON data model has just the right “richness” so that it is an ideal data model for RESTful resources. I would recommend that everybody use it.

In JSON, just three types of data exist:

scalar (number, string, boolean, null). array object Scalar types have just a single value. Arrays contain an ordered list of values of arbitrary type. Objects consist of a unordered set of key:value pairs (also called attributes, not to be confused with XML attributes), where the key is a string and the value can have an arbitrary type. For more detailed information on JSON, see the JSON web site.

In REST style representations mean we can get,

·        How resources get manipulated and presented.

·        Part of the resource state is transferred between client and server

·        Typically JSON or XML or even can be a web page, files, etc..

Discuss the constraints of REST, indicating their use in the domain of web

Constraint,

01.   Client-server

02.   Layered system

03.   Stateless

04.   Cacheable

05.   Code-on-demand

06.   Uniform interface

Client:

server This essentially means that client application and server application MUST be able to evolve separately without any dependency on each other. A client should know only resource URIs and that’s all. Today, this is normal practice in web development so nothing fancy is required from your side. Keep it simple.

Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.

Layered system :

REST allows you to use a layered system architecture where you deploy the APIs on server A, and store data on server B and authenticate requests in Server C, for example. A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way.

Stateless :

Roy elding got inspiration from HTTP, so it reects in this constraint. Make all client-server interaction stateless. Server will not store anything about latest HTTP request client made. It will treat each and every request as new. No session, no history.If client application needs to be a stateful application for the end user, where user logs in once and do other authorized operations thereafter, then each request from the client should contain all the information necessary to service the request – including authentication and authorization details.No client context shall be stored on the server between requests. The client is responsible for managing the state of the application.

Cacheable:

 In today’s world, caching of data and responses is of utmost important wherever they are applicable/possible. The webpage you are reading here is also a cached version of the HTML page. Caching brings performance improvement for client side, and better scope for scalability for a server because the load has reduced.

Code on demand:

 (optional) Well, this constraint is optional. Most of the time you will be sending the static representations of resources in form of XML or JSON. But when you need to, you are free to return executable code to support a part of your application e.g. clients may call your API to get a UI widget rendering code. It is permitted.

Uniform interface:

 As the constraint name itself applies, you MUST decide APIs interface for resources inside the system which are exposed to API consumers and follow religiously. A resource in the system should have only one logical URI and that should provide a way to fetch related or additional data. It’s always better to synonymise a resource with a web page.

All above constraints help you build a truly RESTful API and you should follow them. Still, at times you may nd yourself violating one or two constraints. Do not worry, you are still making a RESTful API – but not “truly RESTful”.

Identify contemporary examples of different types of implementations for the elements of REST style

Component	Examples
User agent	Browser-based-application
Origin server	Server-side application
proxy	CERN Proxy, Netscape Proxy, Gauntlet
gateway	Squid, CGI, Reverse Proxy

Explain how to define the API of Restful web services using Restful URLs

A RESTful API is an application program interface (API) that uses HTTP requests to GET, PUT , POST and DELETE data.

A RESTful API -- also referred to as a RESTful web service -- is based on representational state transfer (REST) technology, an architectural style and approach to communications often used in web services development.

How RESTful APIs work

 A RESTful API breaks down a transaction to create a series of small modules. Each module addresses a particular underlying part of the transaction. This modularity provides developers with a lot of exibility, but it can be challenging for developers to design from scratch. Currently, the models provided by Amazon Simple Storage Service, Cloud Data Management Interface and OpenStack Swift are the most popular.

 A RESTful API explicitly takes advantage of HTTP methodologies dened by the RFC 2616 protocol. They use GET to retrieve a resource; PUT to change the state of or update a resource, which can be an object, le or block; POST to create that resource ; and DELETE to remove it.

 With REST, networked components are a resource you request access to -- a black box whose implementation details are unclear. The presumption is that all calls are stateless; nothing can be retained by the RESTful service between executions.

Because the calls are stateless, REST is useful in cloud applications. Stateless components can be freely redeployed if something fails, and they can scale to accommodate load changes. This is because any request can be directed to any instance of a component; there can be nothing saved that has to be remembered by the next transaction. That makes REST preferred for web use, but the RESTful model is also helpful in cloud services because binding to a service through an API is a matter of controlling how the URL is decoded. Cloud computing and microservices are almost certain to make RESTful API design the rule in the future.

The model-view-controller (MVC) has been the traditional architectural pattern for developing applications having user interface, which later on evolved to MVP and MVVM architectures, as Martin Fowler explains.

dentify the annotations in JAX-RS, explaining their use

Annotation	Description
@Path	The @Path annotation’s value is a relative URI path indicating where the Java class will be hosted: for example, /helloworld. You can also embed variables in the URIs to make a URI path template. For example, you could ask for the name of a user and pass it to the application as a variable in the URI:/helloworld/{username}
@GET	The @GET annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP GET requests. The behavior of a resource is determined by the HTTP method to which the resource is responding.
@POST	The @POST annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP POST requests. The behavior of a resource is determined by the HTTP method to which the resource is responding.
@PUT	The @PUT annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP PUT requests. The behavior of a resource is determined by the HTTP method to which the resource is responding
@DELETE	The @DELETE annotation is a request method designator and corresponds to the similarly named HTTP method. The Java method annotated with this request method designator will process HTTP DELETE requests. The behavior of a resource is determined by the HTTP method to which the resource is responding.

Explain the use and importance of “media type” in JAX-RS

1- View depends both on Controller and Model

 This means there is not a single source of updating the View. In fact, if updating the UI requires data (e.g. from network or database), the View gets it from the Model. If not (e.g. hiding or showing the progress bar or going to another activity), the View gets the updates from the Controller.

 Therefore, for unit testing the View, both Controller and Model must be mocked.

 2- Model is doing too much work

 It does too many things from getting the data from the network/database to informing the Controller about whether it could get the data or not, and even preparing the result to be displayed on the View.

 3- Who controls the UI logic?

 Should the View show the data it gets from the Model directly to the user?

 if true, then the Model is handling the UI logic, which is intuitively not appropriate. Otherwise, View handling the UI logic is not good as well, since the View should only know how display the UI rather than judging on the content it displays.

 JAX-RS: Java API for RESTful Web Services (JAX-RS) is a Java programming language API spec that provides support in creating web services according to the Representational State Transfer (REST) architectural pattern. JAX-RS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints.

All resource methods can consume and produce content of almost any type. If you make a POST request to a URI, such as api/books, the REST API expects the HTTP body to contain a payload that represents the resource it should create.

This resource can be represented using any media type. Although typically, it will be represented in either, JSON or XML, but it could be plain text, binary or a custom format. It doesn’t matter, as long as there is a method in the resource class that can consume that media type.

Web services and SOAP

                                                            Web services and SOAP

Applications that are accessed through browsers are web applications and it is the collection of multiple web pages. These are basically dependent on client server architecture where browser acts as a client which sends the request to server. Afterwards, web pages are rendered as per responses from the server. Purpose of web services is communications between various programs and applications.

 During building any web application, order of focus is on:

·        UI portion[Front end implementation]

·        Functional portion[Back end implementation]

Web services

Web services are mainly used to communicate the information between two systems ignoring UI interaction. Messages are transferred from one application to another application via JSONS and XMLs etc.

 Web services are mainly dependent on back end implementation, UI doesn't have any space. Clients can access only exposed methods of any functionality. Majority of the qa testing services are focusing on automating the web services to speed up the testing for integrated applications.

 Web services are constructed basically to hide the implementation of any product and APIs are exposed to perform specific functions. Web services leads to many advantages for various software testing companies mentioned below:

·        Re-usability of any code

·        Reduced the Complexity

·        Enhanced the features of any product

·        Impact on cost

·        Speed

As communications protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way. WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.

A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types which are abstract collections of operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Hence, a WSDL document uses the following elements in the definition of network services:

• Types– a container for data type definitions using some type system (such as XSD).
• Message– an abstract, typed definition of the data being communicated.
• Operation– an abstract description of an action supported by the service.
• Port Type–an abstract set of operations supported by one or more endpoints.
• Binding– a concrete protocol and data format specification for a particular port type.
• Port– a single endpoint defined as a combination of a binding and a network address.
• Service– a collection of related endpoints.

It is important to observe that WSDL does not introduce a new type definition language. WSDL recognizes the need for rich type systems for describing message formats, and supports the XML Schemas specification (XSD) as its canonical type system. However, since it is unreasonable to expect a single type system grammar to be used to describe all message formats present and future, WSDL allows using other type definition languages via extensibility.

In addition, WSDL defines a common binding mechanism. This is used to attach a specific protocol or data format or structure to an abstract message, operation, or endpoint. It allows the reuse of abstract definitions.

In addition to the core service definition framework, this specification introduces specific binding extensions for the following protocols and message formats:

• SOAP
• HTTP GET / POST
• MIME

Although defined within this document, the above language extensions are layered on top of the core service definition framework. Nothing precludes the use of other binding extensions with WSDL.

Compare and contrast web applications with web services

Web application	Web service
·       User-to-program interaction	·       Program-to-program interaction
·       Static integration of components	·       Dynamic integration of components
·       Monolithic service	·       Service aggregation (micro-services)
·       Ad hoc or proprietary protocol	·       Interoperability (RPC/SOAP/REST)

Discuss what WSDL is and the use of it in the context of web services

WSDL is an XML vocabulary for describing Web services allowing developers to describe Web Services and their capabilities, in a standard manner. Standard format to describe a Web Service (description stack).WSDL specifies three fundamental properties:

01.    What a service does - operations (methods) provided by the service.

02.    How a service is accessed - data format and protocol details.

03.    Where a service is located - Address (URL) details.

The document written in WSDL is also simple called a WSDL (or WSDL document) .WSDL is a contract between the XML (SOAP) Web service and the client who wishes to use this service .The service provides the WSDL document and the Web service client uses the WSDL document to create the stub (or to dynamically decode messages).

The WSDL describes services as collections of network endpoints, or ports. The WSDL specification provides an XML format for documents for this purpose. The abstract definitions of ports and messages are separated from their concrete use or instance, allowing the reuse of these definitions. A port is defined by associating a network address with a reusable binding, and a collection of ports defines a service. Messages are abstract descriptions of the data being exchanged, and port types are abstract collections of supported operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding, where the operations and messages are then bound to a concrete network protocol and message format. In this way, WSDL describes the public interface to the Web service.

WSDL is often used in combination with SOAP and an XML schema to provide Web services over the internet. A client program connecting to a Web service can read the WSDL file to determine what operations are available on the server. Any special data types used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the operations listed in the WSDL file using for example XML over HTTP.

The current version of the specification is 2.0; version 1.1 has not been endorsed by the W3C but version 2.0 is a W3C recommendation. WSDL 1.2 was renamed WSDL 2.0 because of its substantial differences from WSDL 1.1. By accepting binding to all the HTTP request methods (not only GET and POST as in version 1.1), the WSDL 2.0 specification offers better support for Restful web service, and is much simpler to implement. However support for this specification is still poor in software development kits for Web Services which often offer tools only for WSDL 1.1 For example, the version 2.0 of the Business process execution language only supports WSDL 1.1.

Advantages of SOAP

SOAP is the protocol used for data interchange between applications. Below are some of the reasons as to why SOAP is used.

·        When developing Web services, you need to have some of language which can be used for web services to talk with client applications. SOAP is the perfect medium which was developed in order to achieve this purpose. This protocol is also recommended by the W3C consortium which is the governing body for all web standards.

·        SOAP is a light-weight protocol that is used for data interchange between applications. Note the keyword 'light.' Since SOAP is based on the XML language, which itself is a light weight data interchange language, hence SOAP as a protocol that also falls in the same category.

·        SOAP is designed to be platform independent and is also designed to be operating system independent. So the SOAP protocol can work any programming language based applications on both Windows and Linux platform.

·        It works on the HTTP protocol –SOAP works on the HTTP protocol, which is the default protocol used by all web applications. Hence, there is no sort of customization which is required to run the web services built on the SOAP protocol to work on the World Wide Web.

SOAP Building blocks

The SOAP specification defines something known as a "SOAP message" which is what is sent to the web service and the client application.

The diagram below shows the various building blocks of a SOAP Message.

The SOAP message is nothing but a mere XML document which has the below components.

·        An Envelope element that identifies the XML document as a SOAP message – This is the containing part of the SOAP message and is used to encapsulate all the details in the SOAP message. This is the root element in the SOAP message.

·        A Header element that contains header information – The header element can contain information such as authentication credentials which can be used by the calling application. It can also contain the definition of complex types which could be used in the SOAP message. By default, the SOAP message can contain parameters which could be of simple types such as strings and numbers, but can also be a complex object type.

Compare the Port Type and operation elements in WSDL with the java equivalences

Port type	Operation
Port Type element may have one or more operation elements	All patio in a port type must have different names.
In java equivalence port type – java interface	In java equivalence operation – method name
WSDL supports at least a single input and output message	Each operations may define input, output, fault message.

Compare and contrast the binding and service elements in WSDL

Binding	Service
one port Type can be bound to several different protocols by using more than one port	Contain one or more port elements.
Map a Port Type to a specific protocol,	It binds the Web service to a specific network-addressable location
Bindings refer back to port Types by name, just as operations point to messages.	Reference a particular binding, and along with addressing information is wrapped together into a service element to form the final physical, network addressable Web service

Explain how SOAP is used with HTTP

SOAP is an XML-based protocol for accessing web services over HTTP. It has some specification which could be used across all applications. SOAP is known as the Simple Object Access Protocol, but in later times was just shortened to SOAP v1.2. SOAP is a protocol or in other words is a definition of how web services talk to each other or talk to client applications that invoke them. SOAP was developed as an intermediate language so that applications built on various programming languages could talk easily to each other and avoid the extreme development effort.

SOAP Communication Model.

All communication by SOAP is done via the HTTP protocol. Prior to SOAP, a lot of web services used the standard RPC (Remote Procedure Call) style for communication. This was the simplest type of communication, but it had a lot of limitations.

Let's consider the below diagram to see how this communication works. In this example, let's assume the server hosts a web service which provided 2 methods as

·        GetEmployee - This would get all Employee details

·        SetEmployee – This would set the value of the details like employees dept, salary, etc. accordingly.

In the normal RPC style communication, the client would just call the methods in its request and send the required parameters to the server, and the server would then send the desired response.

The above communication model has the below serious limitations

1. Not Language Independent – The server hosting the methods would be in a particular programming language and normally the calls to the server would be in that programming language only.
2. Not the standard protocol – When a call is made to the remote procedure, the call is not carried out via the standard protocol. This was an issue since mostly all communication over the web had to be done via the HTTP protocol.
3. Firewalls – Since RPC calls do not go via the normal protocol, separate ports need to be open on the server to allow the client to communicate with the server. Normally all firewalls would block this sort of traffic, and a lot of configuration was generally required to ensure that this sort of communication between the client and the server would work.

To overcome all of the limitations cited above, SOAP would then use the below communication model

1. The client would format the information regarding the procedure call and any arguments into a SOAP message and sends it to the server as part of an HTTP request. This process of encapsulating the data into a SOAP message was known as Marshalling.
2. The server would then unwrap the message sent by the client, see what the client requested for and then send the appropriate response back to the client as a SOAP message. The practice of unwrapping a request sent by the client is known as Demarshalling.

One thing to note is that SOAP messages are normally auto-generated by the web service when it is called. Whenever a client application calls a method in the web service, the web service will automatically generate a SOAP message which will have the necessary details of the data which will be sent from the web service to the client application.

 A simple SOAP Message has the following elements –

·         The Envelope element

·         The header element

·         The body element

·         The Fault element (Optional)

SOAP Envelope Element

The first bit of the building block is the SOAP Envelope. The SOAP Envelope is used to encapsulate all of the necessary details of the SOAP messages, which are exchanged between the web service and the client application.

The SOAP envelope element is used to indicate the beginning and end of a SOAP message. This enables the client application which calls the web service to know when the SOAP message ends.

The Fault message

When a request is made to a SOAP web service, the response returned can be of either 2 forms which are a successful response or an error response. When a success is generated, the response from the server will always be a SOAP message. But if SOAP faults are generated, they are returned as "HTTP 500" errors.

The SOAP Fault message consists of the following elements.

1.       <faultCode>- This is the code that designates the code of the error. The fault code can be either of any below values

2.       <faultString> - This is the text message which gives a detailed description of the error.

3.       <faultActor> (Optional)- This is a text string which indicates who caused the fault.

4.       <detail>(Optional) - This is the element for application-specific error messages. So the application could have a specific error message for different business logic scenarios.

JAX-WS

JAX-WS is an abbreviation of “Java API for XML-Based Web Services” and is a Java standard API for handling Web service using SOAP etc.

Using JAX-WS, Java object can be sent by converting the same to XML in conformance with SOAP specifications.

Therefore, although information is exchanged in SOAP Web Service using XML, the user can handle the data without being aware of XML structure.

Main Java EE servers like Oracle WebLogic Server or JBoss Enterprise Application Platform use JAX-WS implementation on server side and can easily publish Web service by using the function without adding a specific library.

However, since Tomcat does not implement JAX-WS, a separate JAX-WS implementation library must be added while using Tomcat.

For details, refer “Web service development on Tomcat”.

JAX-WS linkage function of Spring Framework

Spring Framework supports JAX-WS linkage function and implementation can be easily done for both SOAP server and client using this function.

Overview of the recommended access flow using this function is given below. Here, it is assumed that the Web application acting as a SOAP client (Fig. on the left) access SOAP server (fig. on the right).

Testing of web services is one of the important type of software testing approach, which is mainly used to determine the expectations for reliability, functionality, performance, etc.

As these days Automated testing is considered as one of the most trending methodology in the field of software testing, hence testing web apps based on RESTful APIs through automation will provide effective test results. Some of the best & popular tools for web services testing are:

1.     SoapUI,

2.     TestingWhiz,

3.     SOATest

4.     TestMaker,

5.     Postman, etc.

Below three frameworks are widely used in the Web Service testing.

i) SoapUI tool/framework is a popular open source Web Services Testing tool in use since 2005. SoapUI is one of the initial testing tools for WS and has an active and vibrant community. This framework supports cross platform as it is written in Java. SoapUI is a simple and easy to use GUI based tool to develop test suites across the SOAP and RESTful Web Services. It also supports command line (CLI) to execute the tests. SoapUI does support other languages such as Groovy and Javascript.

ii) Jersey client API is an open source implementation of JAX-RS (Java API for XML REST Services) that is used for developing RESTful Web Services. It is created by Oracle (earlier Sun Microsystems). This framework is not a test framework but instead a simple WS client Java APIs to consume in TestNG/JUnit frameworks while developing the tests. A wrapper test framework with common functionality can be created on top of Jersey.

iii) REST Assured framework is a free and open source Java library to work with REST APIs. This framework specialty is that it is very easy to send requests and parse the JSON responses.

Explain the annotations in JAX-WS, providing examples of their use

API for XML-Based Web Services (JAX-WS) relies on the use of annotations to specify metadata associated with web services implementations and to simplify the development of web services. Annotations describe how a server-side service implementation is accessed as a web service or how a client-side Java class accesses web services.

The JAX-WS programming standard introduces support for annotating Java classes with metadata that is used to define a service endpoint application as a web service and how a client can access the web service. JAX-WS supports the use of annotations based on the Metadata Facility for the Java Programming Language (Java Specification Request (JSR) 175) specification, the Web Services Metadata for the Java Platform (JSR 181) specification and annotations defined by the JAX-WS 2.0 and later (JSR 224) specification which includes JAXB annotations. Using annotations from the JSR 181 standard, you can simply annotate the service implementation class or the service interface and now the application is enabled as a web service. Using annotations within the Java source simplifies development and deployment of web services by defining some of the additional information that is typically obtained from deployment descriptor files, WSDL files, or mapping metadata from XML and WSDL into the source artifacts.

Use annotations to configure bindings, handler chains, set names of port Type, service and other WSDL parameters. Annotations are used in mapping Java to WSDL and schema, and at runtime to control how the JAX-WS runtime processes and responds to web service invocations.

It uses annotations,

·         @WebService

·         @WebMethod

·         @OneWay

·         @WebParam

·         @WebResult

·         Etc…