# Idempotent and safe HTTP methods - REST API

DevFeed: [Idempotent and safe HTTP methods - REST API](<https://devfeed.tech/articles/idempotent-and-safe-http-methods-rest-api-24954.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/06/30/idempotent-and-safe-http-methods-why-do-they-matter/>)

Author: umer

Published: 2016-06-30T00:00:00Z

Content type: tutorial

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [HTTP](<https://devfeed.tech/topics/http.md>), [REST API](<https://devfeed.tech/topics/rest-api.md>), [API](<https://devfeed.tech/topics/api.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [http](<https://devfeed.tech/tags/http.md>), [request](<https://devfeed.tech/tags/request.md>), [rest-api](<https://devfeed.tech/tags/rest-api.md>), [server](<https://devfeed.tech/tags/server.md>)

## AI overview

This tutorial explains idempotency and safety in HTTP methods for REST API design. It distinguishes operations whose repeated execution leaves resource state unchanged from safe, read-only operations, and discusses POST and PATCH as examples of non-idempotent methods.

## Source excerpt

If you are designing or building REST APIs, you should be aware of two very important properties of HTTP methods: idempotency and safety. These properties are defined in the HTTP specification. I'm calling them properties, but 'guarantees' would be a better term: you don't automatically get them; you actually need to design for these guarantees because your clients expect you to follow the contract. Let's get the definitions out of the way first and then we'll look at the contract and why it's important to stick to it. Idempotent HTTP Methods An operation is idempotent if it will produce the same results when executed once or multiple times. For example, it doesn't matter how many times I submit a request to set my current location to 'San Francisco'. The final outcome will be the same: the city field in the database is set to 'San Francisco'. On the other hand, a request to POST a new message to the forum is not idempotent: the same message will be stored or sent multiple times if the client. Some people, wrongly, assume that for a request to be idempotent, the same response must be sent back to the client each time: idempotency has nothing to do with the response that's sent back to the client. It's a server side guarantee ensuring that the state of the resource on the server does not change any further after the first request, no matter how many times the request is duplicated. Some idempotent operations have an additional, special property: they do not modify the state on the server side at all. Simply put, these methods are read-only and have absolutely zero side-effects. For example, a query to retrieve my current city doesn't change the database. These types of operations are given a special name: safe or nullipotent methods: Related is the idea of nullipotence: a function is nullipotent if not calling it at all has the same side effects as calling it once or more. In practice, this simply means that the function doesn't have any side effects at all. A databa