Safe Idempotence and Cacheable

Start course
1h 8m

This course takes an in-depth look at Java API for RESTful Web Services, otherwise known as JAX-RS. We also run through some example exam questions that will be useful for anyone who wants to take Oracle's Java EE exam.

Learning Objectives

  • Understand the fundamentals of JAX-RS
  • Learn about the main concepts and components of JAX-RS

Intended Audience

This course is intended for anyone who already has basic knowledge of Java and now wants to learn about Java EE 6.


Basic knowledge of Java programming.


Hello, dear friends. In this video, we will examine the HTTP methods common properties like safe, idempotent, and cacheable, let's begin. HTTP defines request methods to indicate the desired action to be performed for a given resource. These methods are sometimes referred to as HTTP verbs, although they can also be nouns. Often, the resource in consideration corresponds to a file or an output of an executable residing on the server. Once a standardized method is defined, it will have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are implemented or allowed. Each method implements different semantics, but some common features are shared by a group of methods. These are safe, idempotent, or cacheable.

Now, let's examine them one by one. Request methods are considered safe if their defined semantics are essentially read-only. The client does not request and does not expect any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server. This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful that is not entirely read-only or that causes side effects while invoking a safe method. What is important however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, and that is considered safe even though the log storage might become full and crash the server.

Likewise, a safe request initiated by selecting an advertisement on the web will often have the side effect of charging an advertising account. Of the request methods defined by the specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe. So, the other methods are defined unsafe. The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes and cache performance optimization to work without fear of causing harm. In addition, it allows user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content. Now, let's go on with idempotent. Idempotence is sometimes a confusing concept, at least from the academic definition.

From a restful service standpoint, for a service call to be idempotent, clients can make that same call repeatedly while producing the same result. In other words, making multiple identical requests has the same effect as making a single request. Note that while idempotent operations produce the same result on the server, the response itself may not be the same. The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successfully would normally return a 200 or 204 status code, will often return a 404 on subsequent calls unless the service is configured to mark resources for deletion without actually deleting them. However, when the service actually deletes the resource, the next call will not find the resource to delete it and return a 404.

However, the state on the server is the same after each delete call, but the response is different. GET, HEAD, PUT, DELETE, OPTIONS, and TRACE methods are idempotent methods. Request methods can be defined as cacheable to indicate that responses to them are allowed to be stored for future reuse. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable. This specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD. Now we have finished common properties. In the next video, we will create our first RS Service with Jersey. See you in the next video.


About the Author
Learning Paths

OAK Academy is made up of tech experts who have been in the sector for years and years and are deeply rooted in the tech world. They specialize in critical areas like cybersecurity, coding, IT, game development, app monetization, and mobile development.

Covered Topics