Slide 1
Most trusted JOB oriented professional program
DevOps Certified Professional (DCP)

Take your first step into the world of DevOps with this course, which will help you to learn about the methodologies and tools used to develop, deploy, and operate high-quality software.

Slide 2
DevOps to DevSecOps – Learn the evolution
DevSecOps Certified Professional (DSOCP)

Learn to automate security into a fast-paced DevOps environment using various open-source tools and scripts.

Slide 2
Get certified in the new tech skill to rule the industry
Site Reliability Engineering (SRE) Certified Professional

A method of measuring and achieving reliability through engineering and operations work – developed by Google to manage services.

Slide 2
Master the art of DevOps
Master in DevOps Engineering (MDE)

Get enrolled for the most advanced and only course in the WORLD which can make you an expert and proficient Architect in DevOps, DevSecOps and Site Reliability Engineering (SRE) principles together.

Slide 2
Gain expertise and certified yourself
Azure DevOps Solutions Expert

Learn about the DevOps services available on Azure and how you can use them to make your workflow more efficient.

Slide 3
Learn and get certified
AWS Certified DevOps Professional

Learn about the DevOps services offered by AWS and how you can use them to make your workflow more efficient.

previous arrow
next arrow

Understanding REST HTTP method – GET, POST, PUT, HEAD, DELETE in Elasticsearch

REST (Representational State Transfer) was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. REST is an architectural style for designing distributed systems. It is not a standard but a set of constraints, such as being stateless, having a client/server relationship, and a uniform interface. REST is not strictly related to HTTP, but it is most commonly associated with it

Principles of REST

  • Resources expose easily understood directory structure URIs.
  • Representations transfer JSON or XML to represent data objects and attributes.
  • Messages use HTTP methods explicitly (for example, GET, POST, PUT, and DELETE).
  • Stateless interactions store no client context on the server between requests. State dependencies limit and restrict
  • scalability. The client holds session state.

HTTP methods
Use HTTP methods to map CRUD (create, retrieve, update, delete) operations to HTTP requests.

GET (Retrieve information)
Retrieve information. GET requests must be safe and idempotent, meaning regardless of how many times it repeats with the same parameters, the results are the same. They can have side effects, but the user doesn’t expect them, so they cannot be critical to the operation of the system. Requests can also be partial or conditional. example

POST (Create + Update)
Request that the resource at the URI do something with the provided entity. Often POST is used to create a new entity, but it can also be used to update an entity.

PUT (Create + Update)
Store an entity at a URI. PUT can create a new entity or update an existing one. A PUT request is idempotent. Idempotency is the main difference between the expectations of PUT versus a POST request.

DELETE (Remove)
Request that a resource be removed; however, the resource does not have to be removed immediately. It could be an asynchronous or long-running request.


Status codes indicate the result of the HTTP request.

1XX – informational
2XX – success
3XX – redirection
4XX – client error
5XX – server error

PUT vs. POST in RESTful in Elastic Search

A PUT request is idempotent. Idempotency is the main difference between the expectations of PUT versus a POST request.

PUT implies putting a resourcecompletely replacing whatever is available at the given URL with a different thing. By definition, a PUT is idempotent. Do it as many times as you like, and the result is the same. x=5 is idempotent.

You can PUT a resource whether it previously exists, or not (eg, to Create, or to Update)!

POST updates a resource and adds a subsidiary resource, or causes a change. A POST is not idempotent, in the way that x++ is not idempotent.

Good read here

Overall, The PUT is used for update the existing values and POST is using to insert a new value.

At this URL(PUT) vs under this URL(POST)

PUT verb (“store this document at this URL“), we use the POST verb (“store this document under this URL“).

PUT /website/blog/123
  "title": "My first blog entry",
  "text":  "Just trying this out...",
  "date":  "2014/01/01"

Auto-generation of ids(POST) vs specify an id(PUT)

Autogenerated IDs are 20 character long, URL-safe, Base64-encoded GUID strings. These GUIDs are generated from a modified FlakeID scheme which allows multiple nodes to be generating unique IDs in parallel with essentially zero chance of collision.

Thus, only difference, that a POST can be used to achieve auto-generation of ids whereas a PUT is used when you want to specify an id.

It’s all about REST semantics. POST basically that you are posting a request which is going to modify the server state. POST index/type { “foo”: “bar” } will generate an _id server side and will index the document with this _id.

PUT is used to send a resource to the server. PUT index/type/id { “foo”: “bar” } will put or update a document named index/type/id in the server.

Rajesh Kumar
0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments
Would love your thoughts, please comment.x