HTTP Standard Status Codes

The status codes defined in HTTP are the following:

  • 200: Success
  • 201: Created
  • 401: Unauthorized
  • 404: Resource Not Found
  • 500: Server Error

Spring Boot – Introduction to RESTful Web Services

RESTful Web Services REST stands for REpresentational State Transfer. It was developed by Roy Thomas Fielding, one of the principal authors of the web protocol HTTP. Consequently, REST was an architectural approach designed to make the optimum use of HTTP protocol. It uses the concepts and verbs already present in HTTP to develop web services. This made REST incredibly easy to use and consume, so much so that it is the go-to standard for building web services today.

A resource can be anything, it can be accessed through a URI (Uniform Resource Identifier). Unlike SOAP, REST does not have a standard messaging format. We can build REST web services using many representations, including both XML and JSON, although JSON is the more popular option. An important thing to consider is that REST is not a standard but a style whose purpose is to constrain our architecture to a client-server architecture and is designed to use stateless communication protocols like HTTP.

Similar Reads

Important Methods of HTTP

The main methods of HTTP we build web services for are:...

HTTP Standard Status Codes

The status codes defined in HTTP are the following:...

Uses of Spring Boot – REST

The web services are completely stateless. The service producer and consumer have a mutual understanding of the context and content being passed along. When there is already some catching infrastructure present since we can use those to enhance performance in a REST API. This is so since idempotent requests like GET, PUT, and DELETE are all cacheable. Often Bandwith is of significant importance to organizations. Rest is instrumental then as there are no overhead headers from the SOAP XML payload. Web service delivery or aggregation into existing websites can be enabled easily with a RESTful style. It’s simply not required to overhaul the architecture since we can expose the API as an XML and consume the HTML web pages, thus still maintaining the external contract of the service....

Contact Us