From eb2a6cb43c620fdb7fa610b1bab6beec89c6d2b3 Mon Sep 17 00:00:00 2001
From: Luis de Bethencourt <luis@debethencourt.com>
Date: Sat, 11 Mar 2017 16:59:58 +0000
Subject: [PATCH] Fix typo in RPC section (#17)

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 8ad8281..dc2e1e6 100644
--- a/README.md
+++ b/README.md
@@ -1428,7 +1428,7 @@ HTTP APIs following **REST** tend to be used more often for public APIs.
 #### Disadvantage(s): RPC
 
 * RPC clients become tightly coupled to the service implementation.
-* A new API must be definied for every new operation or use case.
+* A new API must be defined for every new operation or use case.
 * It can be difficult to debug RPC.
 * You might not be able to leverage existing technologies out of the box.  For example, it might require additional effort to ensure [RPC calls are properly cached](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/) on caching servers such as [Squid](http://www.squid-cache.org/).