Stateless protocol

No client state on the server.

A stateless protocol does not require the server to retain session information or status about each communications partnerfor the duration of multiple requests.

The session is stored on the client. Server does not store any state about the client session on the server side.

Stateless protocol is a communications protocol that treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of request and response.

Examples

Stateless protocols include the Internet Protocol (IP) which is the foundation for the Internet, and the Hypertext Transfer Protocol (HTTP) which is the foundation of data communication for the World Wide Web.

HTTP is a Stateless protocol, meaning that each request message can be understood in isolation. Contrast this with a traditional FTP server that conducts an interactive session with the user. During the session, a user is provided a means to be authenticated and set various variables (working directory, transfer mode), all stored on the server as part of the user's state.

Advantages:

For a service which is used by 10's of thousands of concurrent users, We should make our service stateless.

It is an overall simpler implementation and you have a single code path instead of a bunch of server side logic to maintain a bunch of session state.

The stateless design simplifies the server design because there is no need to dynamically allocate storage to deal with conversations in progress.

If a client dies in mid-transaction, no part of the system needs to be responsible for cleaning up the present state of the server.

Disadvantage:

A disadvantage of statelessness is that it may be necessary to include additional information in every request, and this extra information will need to be interpreted by the server.

Stateful protocol

In contrast, a protocol which requires keeping of the internal state on the server is known as a stateful protocol.

https://en.wikipedia.org/wiki/Stateless_protocol

Element : load-on-startup

     <servlet>

           <servlet-name>rest</servlet-name>

           <servlet-class>

                org.springframework.web.servlet.DispatcherServlet

           </servlet-class>

           <load-on-startup>1</load-on-startup>

     </servlet>

Data Type: integer

Value >= 0: servlet is loaded when the web-app is deployed or when the server starts.

Value < 0: servlet is loaded whenever the container feels like.

The load-on-startup element indicates that this servlet should be loaded (instantiated and have its init() called) on the startup of the web application.

The optional contents of these elements must be an integer indicating the order in which the servlet should be loaded.

If the value is a negative integer, or the element is not present, the container is free to load the servlet whenever it chooses.

If the value is a positive integer or 0, the container must load and initialize the servlet as the application is deployed. The container must guarantee that servlets marked with lower integers are loaded before servlets marked with higher integers. The container may choose the order of loading of servlets with the same load-on-start-up value.

What is the difference between thin and thick client?

The thin vs. thick distinction usually refers to how much processing or "business logic" is done on the client.

Thin client:

Basically, a thin client is a web based application and most of the processing is done on the server side.

Example:

Web browser is the classic example of thin client. It can be the client application for anyone's server application.

The client can be generic like a web browser, and since most of the logic takes places on the central server, it's much easier to push updates out to the clients.

Advantage of thin clients is they make fewer demands on the client machine, which can be anything from a computer to a smart phone to a household device like a blender or TV set top box.

Thick client:

A thick client is more like a standalone application, which run on the client machine and communicates with the server less frequently.

With thick client, there won't be much processing via the network. In a way, it will be a much faster option if your network is slow or congested.

Example:

A virus scanner is a good example. It downloads new virus definitions from the server, but then runs its scan on the client machine without further communication to the server.

Advantage of thick clients is that the performance isn't tied to the load on the server, and the speed of the network connection.

XML Declaration

XML Declaration

The XML declaration appears as the first line in an XML document.

The XML declaration is not required, however, if used it must be the first line in the document and no other content or white space can precedeit.

version number

The version number is mandatory. Although number might change for future versions of XML, 1.0 is the current version.

<?xml version="1.0"?>

encoding declaration

The encoding declaration is optional.

If it is used, the encoding declaration must appear immediately after the version information in the XML declaration, and must contain a value representing an existing character encoding.

<?xml version="1.0" encoding="UTF-8"?>

The encoding declaration identifies which encoding is used to represent the characters in the document. Although XML parsers can determine automatically if a document uses the UTF-8 or UTF-16 Unicode encoding, this declaration should be used in documents that support other encodings.

Example:ISO-8859-1 (Latin 1).

<?xml version="1.0" encoding="ISO-8859-1"?>

Note:

XML is case sensitive however Case in the value specified is not considered by the encoding declaration. "ISO-8859-1" is the equivalent of "iso-8859-1".

standalone declaration

The standalone declaration is optional. If used, the standalone declaration must appear last in the XML declaration.

<?xml version="1.0" encoding="UTF-8"standalone="yes"?>

The standalone declaration indicates whether a document relies on information from an external source, such as external document type definition (DTD), for its content.

If the standalone declaration has a value of "yes", the parser will report an error if the document references an external DTD or external entities.

Leaving out the standalone declaration produces the same result as including a standalone declaration of "no". The XML parser will accept external resources, if there are any, without reporting an error.

What is XML and Its benefits?

What is XML?

XML stands for EXtensible Markup Language.

XML was designed to store and transport data.

XML was designed to be both human- and machine-readable.

XML tags are not predefined. You must define your own tags.

XML is platform independent and language independent.

Example

Version is a tag used to show which version of XML is used.

<?xml version="1.0" encoding="UTF-8"?>

<UserInfo>

      <name>Rajesh</name>

      <age>25</age>

      <occ>Software dev</occ>

      <address>Mathura</address>

</UserInfo>

<root>

      <child>

            <subchild>.....</subchild>

      </child>

</root>

What are the benefits of XML?

Simplicity: Easy to read and understand the XML coded information.

Openness: Endorsed by all software industry market leaders.

Extensibility: We can define own tags as It is extensible because it has no fixed set of tags.

Self-descriptive:XML documents do not need special schema set-up like traditional databases to store data. XML documents can be stored without such definitions, because they contain metadata in the form of tags and attributes.

Scalable:XML is not in binary format so you can create and edit files with anything and it is also easy to debug.

Fast access: XML documents are arranged in hierarchical form so it is comparatively faster.

JSON and Its Advantage over XML

JSON

JSON stands for JavaScript Object Notation. JSON objects are used for transferring data between server and client, XML serves the same purpose.

JSON basically has key-value pairs.

employee = {

   "firstName" : "rajesh",

   "role" : "developer",

   "age" :  "25"

};

Features of JSON:

It is light-weight.

It is language independent

Easy to read and write

Text based, human readable data exchange format

Why use JSON?

Standard Structure: Standard structure of JSON objects makes developers job easy to read and write code, because they know what to expect from JSON.

Light weight: When working with AJAX, it is important to load the data quickly and asynchronously without requesting the page re-load. Since JSON is light weighted, it becomes easier to get and load the requested data quickly.

Scalable:JSON is language independent, which means it can work well with most of the modern programming language.

Let’s say if we need to change the server side language, in that case it would be easier for us to go ahead with that change as JSON structure is same for all the languages.

JSON vs. XML

JSON style:

{"students":[

   {"name":"Rajesh", "age":"25", "city":"Mathura"},

   {"name":"Sattu", "age":"26", "city":"Delhi"},

   {"name":"Rahul", "age":"28", "city":"Agra"},

]}

XML style:

<students>

  <student>

    <name>Rajesh</name> <age>25</age> <city>Mathura</city>

  </student>

  <student>

    <name>Sattu</name> <age>26</age> <city>Delhi</city>

  </student>

  <student>

    <name>Rahul</name> <age>28</age> <city>Agra</city>

  </student>

</students>

As you can clearly see JSON is much more light-weight compared to XML. Also, in JSON we take advantage of arrays that is not available in XML.

@RequestBody, @ResponseBody, @RequestHeader and @CookieValue

@RequestBody

org.springframework.web.bind.annotation.RequestBody

@Target(value={PARAMETER})

@Retention(value=RUNTIME)

Annotation indicating a method parameter should be bound to the body of the web request.

The body of the request is passed through an HttpMessageConverter to resolve the method argument depending on the content type of the request.

Optionally, automatic validation can be applied by annotating the argument with @Valid.

Supported for annotated handler methods in Servlet environments.

@ResponseBody

org.springframework.web.bind.annotation.ResponseBody

@Target(value={METHOD, TYPE})

@Retention(value=RUNTIME)

Annotation that indicates a method return value should be bound to the web response body. Supported for annotated handler methods in Servlet environments.

As of version 4.0 this annotation can also be added on the type level in which case it is inherited and does not need to be added on the method level.

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.http.MediaType;

import org.springframework.stereotype.Controller;

import org.springframework.web.bind.annotation.RequestBody;

import org.springframework.web.bind.annotation.RequestMapping;

import org.springframework.web.bind.annotation.RequestMethod;

import org.springframework.web.bind.annotation.ResponseBody;

import org.apache.log4j.Logger;

import com.abusecore.model.Count;

import com.abusecore.model.Status;

import com.abusecore.model.Ticket;

import com.abusecore.services.IDataServices;

@Controller

@RequestMapping("/AbuseCore-1")

public class RestController {

       @Autowired

       IDataServices dataServices;

       /** Logger class to display logs. */

       static final Logger logger = Logger.getLogger(RestController.class);

       @RequestMapping(value = "/count-tickets.json", method = RequestMethod.GET)

       public @ResponseBody Count getTicketsCount() {

              Count count = dataServices.getTicketsCount();

              logger.info("total tickets :" + count);

              return count;

       }

       @RequestMapping(value = "/create", method = RequestMethod.POST,

                     consumes = MediaType.APPLICATION_JSON_VALUE)

       public @ResponseBody Status addEmployee(@RequestBody Ticket ticket) {

              try {

                     dataServices.addEntity(ticket);

                     return new Status(1, "Ticket added Successfully !");

              } catch (Exception e) {

                     // e.printStackTrace();

                     return new Status(0, e.toString());

              }

       }

}

@RequestHeader

org.springframework.web.bind.annotation.RequestHeader

@Target(value={PARAMETER})

@Retention(value=RUNTIME)

Annotation which indicates that a method parameter should be bound to a web request header.

Supported for annotated handler methods in Servlet and Portlet environments.

If the method parameter is Map<String, String> or MultiValueMap<String, String>, or HttpHeaders then the map is populated with all header names and values.

@CookieValue

org.springframework.web.bind.annotation.CookieValue

@Target(value={PARAMETER})

@Retention(value=RUNTIME)

Annotation which indicates that a method parameter should be bound to an HTTP cookie. Supported for annotated handler methods in Servlet and Portlet environments.

The method parameter may be declared as type javax.servlet.http.Cookie or as cookie value type (String, int, etc).