RESTful Architecture

Source: https://www.katalon.com/resources-center/blog/web-api-testing-interview-questions/ https://www.tutorialspoint.com/restful/restful_questions_answers.htm

REST

REST (REpresentational State Transfer)

Architectural style for developing web services which exploit the ubiquity of HTTP protocol and uses HTTP method to define actions.

Revolves around resource. Every component being a resource that can be accessed through a shared interface using standard HTTP methods.

A REST Server provides access to resources and REST client accesses and makes these resources available.

Each resource is identified by URIs or global IDs.

REST uses multiple ways to represent a resource, such as JSON, text, and XML. XML and JSON are nowadays the most popular representations of resources.

Webservices

Collection of open protocols and standards used for exchanging data between applications or systems.

RESTFUL Web Services

RESTFUL is referred for web services written by applying REST architectural concept are called RESTful services, it focuses on system resources and how state of resource should be transported over HTTP protocol to different clients written in different language. In RESTFUL web service HTTP methods like GET, POST, PUT and DELETE can be used to perform CRUD operationsThat's a tough question but thankfully, our team is on it. Please bear with us while we're investigating.

2 kinds of Web Services:

1. SOAP (Simple Object Access Protocol). An XML-based method to expose web services.

2. RESTful web services. They use HTTP methods to implement the concept of REST architecture. A RESTful web service usually defines a URI, Uniform Resource Identifier a service, provides resource representation like JSON and a set of HTTP methods.

Key features of REST

• Stateless. The SERVER has no state (or session data)

• The server could be restarted between two calls as every data is passed to the server

• Web service mostly uses POST method to make operations, whereas REST uses GET to access resources

Stateless

A RESTful web service should not keep a client state on server.

It is responsibility of the client to pass its context to server and then server can store this context to process client's further request.

Ex.: session maintained by server is identified by session identifier passed by the client.

Pros:

• Web services can treat each method request independently.

• Web services need not to maintain client's previous interactions. It simplifies application design.

• As HTTP is itself a statelessness protocol, RESTful Web services work seamlessly with HTTP protocol.

Cons:

• Web services need to get extra information in each request and then interpret to get the client's state in case client interactions are to be taken care of.

Architectural style for creating web API?

• HTTP for client server communication

• XML/JSON as formatting language

• Simple URI as the address for the services

• Stateless communication

HTTP methods supported by REST

• GET: Requests a resource at the requested URL. It can be cached. It remains in the browser history. Has length restrictions. Should never be used when dealing with sensitive data.

• POST: Submits information to the service for processing; it should typically return the modified or new resource. Not cacheable.

• PUT: Updates the resource at the requested URL

• DELETE: Removes the resource at the requested URL

• OPTIONS: Indicates which techniques are supported

• HEAD: Returns meta information bout the request URL

Resources

Any content is a resource, which can be either text files, HTML pages, images, videos or dynamic business information.

REST Server gives access to resources and modifies them, where each resource is identified by URIs/ global IDs.

The key element of a RESTful design.

Unlike SOAP web services, in REST you view the product data as a resource and this resource should contain all the required information.

REST vs AJAX

REST	AJAX
Has a URL structure and a request/response pattern that revolve around the use of resources A type of software architecture and a method for users to request data or information from servers Requires the interaction between the customer and server	Request are sent to the server by using XMLHttpRequest objects. The response is used by the JavaScript code to dynamically alter the current page Is a set of technologies to dynamically update parts of UI without having to reload the page Eliminates the interaction between the customer and server asynchronously

REST vs SOAP

REST	SOAP
Is a service architecture and design for network-based software architectures Supports many different data formats Reads can be cached A REST client is more like a browser; it knows how to standardized methods and an application has to fit inside it Faster than SOAP Uses the HTTP headers to hold meta information	Is a protocol through which two computer communicates by sharing XML document Permits only XML Reads cannot be cached Is a like custom desktop application, closely connected to the server Slower than REST Runs on HTTP but envelopes the message

PUT vs POST

PUT and POST operation are quite similar, except the terms of the result generated by them.

PUT

• Puts a file or resource at a particular URI and exactly at that URI.

• If there is already a file or resource at that URI, PUT changes that file or resource. If there is no resource or file there, PUT makes one

• Idempotent: invoking it any number of times will not have an impact on resources.

• Therefore: cacheable

POST

• Sends data to a particular URI

• Expects the resource at that URI to deal with the request. The web server at this point can decide what to do with the data in the context of specified resource

• Not idempotent, therefore not cacheable. If you retry the request N times, you will end up having N resources with N different URIs created on server.

PUT vs PATCH

PUT

• Replaces the entire resource

PATCH

• Meant to apply a delta to an existing resource. Is, just changes specific part of the resource.

Messaging

A client sends a message in form of a HTTP Request and server responds in form of a HTTP Response.

These messages contain message data and metadata i.e. information about message itself.

Parts of an HTTP request

1. An action showing HTTP methods like GET, PUT, POST, DELETE.

2. URI (Uniform Resource Identifier): identifier for the resource on the server.

3. HTTP Version: indicates HTTP version. Ex.: HTTP v1.1.

4. Header: carries metadata (as key-value pairs) for the HTTP Request message. Metadata could be a client (or browser) type, format supported by the client, format of a message body format, cache settings, and so on.

5. Body: indicates the message content or resource representation.

Parts of an HTTP Response

• Status/Response Code: Indicates Server status for the requested resource. Ex.: 404 means resource not found. 200 means response is ok.

• HTTP Version: Indicates HTTP version. Ex.: HTTP v1.1 .

• Response Header. Contains metadata for the HTTP Response message as key-value pairs. Ex.: content length, content type, response date, server type etc.

• Response Body. Response message content or Resource representation.

URI

Uniform Resource Identifier

A string of characters designed for unambiguous identification of resources and extensibility via the URI scheme.

The purpose of a URI is to locate a resource(s) on the server hosting of the web service.

Format:

<protocol>://<service-name>/<ResourceType>/<ResourceID>.

Payload

The actual data you are interested in transporting.

This is differentiated from the things that wrap the data for transport like the HTTP/S Request/Response headers, authentication, etc.

Caching

Storing server response in client itself so that a client needs not to make server request for same resource again and again.

A server response should have information about how a caching is to be done so that a client caches response for a period of time or never caches the server response.

Security

As RESTful Web Services work with HTTP URL Paths, it is very important to safeguard a RESTful Web Service in the same manner as a website is secured.

Following are the best practices to be adhered to while designing a RESTful Web Service −

• Validation − Validate all inputs on the server. Protect your server against SQL or NoSQL injection attacks.

• Session Based Authentication − Use session based authentication to authenticate a user whenever a request is made to a Web Service method.

• No Sensitive Data in the URL − Never use username, password or session token in a URL, these values should be passed to Web Service via the POST method.

• Restriction on Method Execution − Allow restricted use of methods like GET, POST and DELETE methods. The GET method should not be able to delete data.

• Validate Malformed XML/JSON − Check for well-formed input passed to a web service method.

• Throw generic Error Messages − A web service method should use HTTP error messages like 403 to show access forbidden, etc.

HTTP Status Codes

HTTP Code	Description
200	OK − shows success.
201	CREATED − resource has been successfully created using POST or PUT. Returns link to the newly created resource using the location header.
204	NO CONTENT − response body is empty. Example, a DELETE request.
304	NOT MODIFIED − used to reduce network bandwidth usage in case of conditional GET requests. Response body should be empty. Headers should have date, location, etc.
400	BAD REQUEST − an invalid input has been provided. Example, validation error, missing data.
401	UNAUTHORIZED − the user is using invalid or wrong authentication token.
403	FORBIDDEN − the user is not having access to the method being used. Example, Delete access without admin rights.
404	NOT FOUND − the method is not available.
409	CONFLICT − conflict situation while executing the method. Example, adding duplicate entry.
500	INTERNAL SERVER ERROR − the server has thrown some exception while executing the method.