eugeniop · December 17, 2015 12:19
diff --git a/gistfile1.txt b/gistfile1.txt
 _REST_, or Representational State Transfer is probably one of the most misunderstood terms in Web API development today. Where REST is misunderstood is that most people use REST as synonymous with anything that is easy to access over HTTP and forget about the constraints completely. 

 The term's roots are from Roy Fielding's previously mentioned dissertation on network based architecture (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm). In it, Roy describes REST as an architectural style for distributed hypermedia systems. What he is saying is that REST is not a technology, it is not a framework, and it is not a design pattern. It is a style. There is no "One True Way" to do REST and as a result, many flavours of RESTful systems. What they have in common however, and  most importantly, is that RESTful systems manifest iteself in a set of constraints: X, Y, Z.

 The other part of the misunderstanding is that you MUST build a RESTful system. This is also not the case. The RESTful constraints are designed to create a system that achieves a certain set of goals in particular a system that can evolve over a long period of time and which can tolerate many different clients, and many different changes without breaking those clients. However, building a RESTful system is not free, and not necessarily easy. For this reason this book does not focus on REST but rather focuses on evolvability and techniques to achieve that.

 In other words, focus on the needs of your system and not whether you can stamp it with a "REST" badge or not.
	_REST_, or Representational State Transfer is probably one of the most misunderstood terms in Web API development today. Where REST is misunderstood is that most people use REST as synonymous with anything that is easy to access over HTTP and forget about the constraints completely.

	The term's roots are from Roy Fielding's previously mentioned dissertation on network based architecture (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm). In it, Roy describes REST as an architectural style for distributed hypermedia systems. What he is saying is that REST is not a technology, it is not a framework, and it is not a design pattern. It is a style. There is no "One True Way" to do REST and as a result, many flavours of RESTful systems. What they have in common however, and most importantly, is that RESTful systems manifest iteself in a set of constraints: X, Y, Z.

	The other part of the misunderstanding is that you MUST build a RESTful system. This is also not the case. The RESTful constraints are designed to create a system that achieves a certain set of goals in particular a system that can evolve over a long period of time and which can tolerate many different clients, and many different changes without breaking those clients. However, building a RESTful system is not free, and not necessarily easy. For this reason this book does not focus on REST but rather focuses on evolvability and techniques to achieve that.

	In other words, focus on the needs of your system and not whether you can stamp it with a "REST" badge or not.