TheCloneArmy/RestApiGuide
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Added some content and fixed the title on the Idempontence page.

Browse Source
This commit is contained in:
Todd Fredrich
2013-09-17 17:42:42 -06:00
parent da3d43fc80
commit 4c7b4c8939
1 changed files with 18 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
lessons/idempotency.html
View File

@ -2,7 +2,7 @@
<html lang="en"> <html lang="en">
<head> <head>
<meta charset="utf-8"> <meta charset="utf-8">
<title>What is REST?</title> <title>What is Idempotency?</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="description" content="Idempotency or Idempotence, definition in a non-academic way, specifically in REST APIs"> <meta name="description" content="Idempotency or Idempotence, definition in a non-academic way, specifically in REST APIs">
<meta name="author" content="Todd Fredrich, Pearson eCollege"> <meta name="author" content="Todd Fredrich, Pearson eCollege">
@ -61,10 +61,25 @@
</div> </div>
</div> </div>
<div class="row"> <div class="row">
<div class="span12">
<h2>Idempotence</h2>
</div>
<div class="span12"> <div class="span12">
<p>Idempotence is a funky word that often hooks people. Idempotence is sometimes a confusing concept, at least from the academic definition.</p> <p>Idempotence is a funky word that often hooks people. Idempotence is sometimes a confusing concept, at least from the academic definition.</p>
<p>Turns out, with respect to a REST API, idempotency just means that you can make one call to an API or many calls to that API and have the same end result. For instance, calling update (via PUT, say) with the same data will result in the same data being stored on the server.</p> <p>From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result—operating much like a “setter” method in a programming language. 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 (side effects), the response itself may not be the same (e.g. a resource's state may change between requests).</p>
<p>That&sbquo;s all there is to it. Watch the video to take a humorous deeper-look at idempotence.</p> <p>The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successful would normally return a 200 (OK) or 204 (No Content), will often return a 404 (Not Found) 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.</p>
<p>GET, HEAD, OPTIONS and TRACE methods are defined as safe, which makes them idempotent also. Read the section on safety below.</p>
</div>
</div>
<div class="row">
<div class="span12">
<h2>Safetey</h2>
</div>
<div class="span12">
<p>Idempotence is a funky word that often hooks people. Idempotence is sometimes a confusing concept, at least from the academic definition.</p>
<p>From a RESTful service standpoint, for an operation (or service call) to be idempotent, clients can make that same call repeatedly while producing the same result—operating much like a “setter” method in a programming language. 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 (side effects), the response itself may not be the same (e.g. a resource's state may change between requests).</p>
<p>The PUT and DELETE methods are defined to be idempotent. However, there is a caveat on DELETE. The problem with DELETE, which if successful would normally return a 200 (OK) or 204 (No Content), will often return a 404 (Not Found) 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.</p>
<p>GET, HEAD, OPTIONS and TRACE methods are defined as safe, which makes them idempotent also. Read the section on safety below.</p>
</div> </div>
</div> </div>
<hr> <hr>