Introduction to RESTful Web Services

HTTP History

HTTP/1.0

• Development of HTTP was started by Tim Berners-Lee of CERN in 1989

• HTTP/0.9 is the Original HTTP proposal by Tim Berners-Lee

• Started as a telnet friendly protocol

• HTTP/1.0 - From 1991 to 1995 the HTTP/HTML specifications grew rapidly

• New software known as a “web browser” emerged

• HTTP standards were developed by:

  • IETF - Internet Engineering Task Force

  • W3C - World Wide Web Consortium

HTTP/1.1

• HTTP/1.1 - Originally released in 1997

• Solved a lot of ambiguities from earlier versions

• Added support for keep alive connections, chunked encoding transfers, byte-range requests, transfer encodings, and request pipelining

• HTTP/1.1 - Updated by RFC 2616 in 1999

• Updated again by RFC 7230 in 2014

• Still in use today

• Request & Response: Added encoding, charset, and cookies

HTTP/2

• HTTP/2 Standardized in 2015

  • Originally named HTTP/2.0

• Supported by most servers and browsers by the end of 2015

• As of October 2021, 47% of the top 10 Million websites supported HTTP/2

• Has high level of compatibility with HTTP/1.1

• Transport Performance was a focus of HTTP/2

• Improves page load speed by:

  • Lower Latency

  • Higher Throughput

• Differences from HTTP/1.1 are largely transparent for web developers

HTTP/3

• HTTP/3 was accepted by IETF in November of 2018

• As of summer of 2022, HTTP/3 is supported by 73% of browsers and 25% of the top 10 million websites.

• Builds on concepts of HTTP/2

• Most significant change is use of the QUIC network protocol rather than TCP

• No significant changes for developers

• Adoption in the Java community is early and evolving

HTTP Request Methods

• Request methods, also known as verbs, are used to indicate the desired action to be performed
• GET - is a request for a resource (html file, javascript file, image, etc)
• GET - is used when you visit a website.
• HEAD - is like GET, but only asks for meta information without the body.

• POST - is used to post data to the server.
  • Typical use case for POST is to post form data to the server (like a checkout form)

• PUT - is a request for the enclosed entity be stored at the supplied URI. If the entity exists, it is expected to be updated.
• POST is a create request
• PUT is a create OR update request

• DELETE - Is a request to delete the specified resource
• TRACE - Will echo the received request. Can be used to see if request was altered by intermediate servers
• OPTIONS - Returns the HTTP methods supported by the server for the specified URL
• CONNECT - Converts the request to a transparent TCP/IP tunnel, typically for HTTPS through an unencrypted HTTP proxy
• PATCH - Applies partial modifications to the specified resource

Safe Methods

• Safe Methods are considered safe to use because they only fetch information and do not cause changes on the server
• The Safe Methods are: GET, HEAD, OPTIONS, and TRACE

Idempotent Methods

• Idempotency - A quality of an action such that repetitions of the action have no further effect on the outcome
• PUT and DELETE are Idempotent Methods
• Safe Methods (GET, HEAD, TRACE, OPTIONS) are also Idempotent
• Being truly Idempotent is not enforced by the protocol

Non-idempotent Methods

• POST is NOT Idempotent
• Multiple Posts are likely to create multiple resources
• Ever seen websites asking you to click submit only once?

HTTP Status Codes

• 100 series are informational in nature
• 200 series indicate successful request
• 300 series are redirections
• 400 series are client errors
• 500 series are server side errors

Common HTTP Status Codes

• 200 Okay; 201 Created; 204 Accepted
• 301 Moved Permanently
• 400 Bad Request; 401 Not Authorized; 404 Not Found
• 500 Internal Server Error; 503 Service Unavailable