From 3cf37af574f6cf4e4ff458f9a3123c8b42d062bb Mon Sep 17 00:00:00 2001 From: Ben Alpert Date: Sat, 20 Jun 2015 16:49:33 -0700 Subject: [PATCH] Fix typo in blog post (#4183) (cherry picked from commit df05c6efb8095bdf6f02c1a3ed30e5c8ad702c04) --- docs/_posts/2015-05-01-graphql-introduction.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/_posts/2015-05-01-graphql-introduction.md b/docs/_posts/2015-05-01-graphql-introduction.md index 9faaad8ac2..3a96033515 100644 --- a/docs/_posts/2015-05-01-graphql-introduction.md +++ b/docs/_posts/2015-05-01-graphql-introduction.md @@ -71,7 +71,7 @@ Obviously GraphQL is not the first system to manage client-server interactions. REST an acronym for Representational State Transfer, which is an architectural style rather than a formal protocol. There is actually much debate about what exactly REST is and is not. We wish to avoid such debates. We are interested in the typical attributes of systems that *self-identify* as REST, rather than systems which are formally REST. -Objects in a typical REST system are addressable by URI and interacted with using verbs in the HTTP protocol. An HTTP GET to a particular URI fetches and object and returns a server-specified set of fields. An HTTP PUT edits an object; an HTTP DELETE deletes an object; and so on. +Objects in a typical REST system are addressable by URI and interacted with using verbs in the HTTP protocol. An HTTP GET to a particular URI fetches an object and returns a server-specified set of fields. An HTTP PUT edits an object; an HTTP DELETE deletes an object; and so on. We believe there are a number of weakness in typical REST systems, ones that are particularly problematic in mobile applications: