<?xml version="1.0" encoding="UTF-8"?><rss version="0.92">
<channel>
	<title>Lawrence Wagerfield</title>
	<link>http://www.lawrence.wagerfield.com</link>
	<description>Fragmenting The Heap Since 2000</description>
	<lastBuildDate>Wed, 31 Aug 2011 22:08:59 +0000</lastBuildDate>
	<docs>http://backend.userland.com/rss092</docs>
	<language>en</language>
	<!-- generator="WordPress/3.2.1" -->

	<item>
		<title>Can REST Expose Course Grained APIs?</title>
		<description><![CDATA[Firstly, I must state that I am an avid fan of REST and always try to use it where possible. I researched REST for my bachelors dissertation at University, and whilst I found it made a lot of academic sense, I always struggled to see its commercial viability for exposing complex APIs. My doubts have since been [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/can-rest-expose-course-grained-apis</link>
			</item>
	<item>
		<title>Isolating Class Interactions</title>
		<description><![CDATA[This post defines 3 horizontal tiers for decoupling code by isolating class interactions within and between packages. Horizontal tiers exist as a contrast to standard tiers (or 'vertical tiers'), which are concerned with isolating levels of service as opposed to class interactions. These horizontal tiers consist of factories, providers and logic, which respectively correlate with [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/isolating-class-interactions</link>
			</item>
	<item>
		<title>REST Principles</title>
		<description><![CDATA[This article composes various findings from technical papers, journals, books and of course Fielding's original dissertation: Architectural Styles and the Design of Network-based Software Architectures. Some aspects of this article are perhaps a little vague, but should hopefully provide a good starting point to those learning REST. I'd strongly recommend Fielding's dissertation and 'RESTful Web Services' by Richardson &#38; Ruby; [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/rest-principles</link>
			</item>
	<item>
		<title>REST Principles: Resources (1 of 8)</title>
		<description><![CDATA[REST promotes a resource-oriented-architecture (ROA) whereby resources are defined as "any information that can be named" (Fielding, 2000, p. 88). In a more practical sense, a resource is something that can be represented on a computer as a stream of bits. All resources must have at least one URI, although the decision as to which [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/rest-principles-resources</link>
			</item>
	<item>
		<title>REST Principles: Representations (2 of 8)</title>
		<description><![CDATA[REST defines resources as having one-or-more representations (Fielding, 2000). Representations provide tangible content for each of the service's resources using specific formats. Person Photograph House address Biography Person resource (top) with representations (bottom). A common misconception is that resources are the data. They are not. Resources merely symbolise the concepts and ideas behind how a [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/rest-principles-representations</link>
			</item>
	<item>
		<title>REST Principles: Addressability (3 of 8)</title>
		<description><![CDATA[An addressable service exposes a URI for every resource it might conceivably serve (Richardson &#38; Ruby, 2007). Following this principle allows clients to harness the power of URIs, enabling them to bookmark and reference resources. The URI concept is often taken for granted in this sense: up until the mid 1990s FTP wasn't addressable via [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/rest-principles-addressability</link>
			</item>
	<item>
		<title>REST Principles: Statelessness (4 of 8)</title>
		<description><![CDATA[A stateless service processes every request in complete isolation. This is achieved by requiring that each request includes all necessary information for fulfilment, thus moving session-state from the server-side to the client-side. Fielding (2000, p. 78) argues that all services should be stateless, and the advantages gained by taking this approach usually outweigh the more [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/rest-principles-statelessness</link>
			</item>
	<item>
		<title>REST Principles: Descriptive URIs (5 of 8)</title>
		<description><![CDATA[URIs should be descriptive and well structured. It is also important to remember that URIs designate resources, not methods. Therefore it is never appropriate to include verbs inside path names. Relationships can be described through hierarchical paths (Berners-Lee, 1996) and querystrings should be avoided since they fail to describe relationships between URI parts (Bone, 2002). [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/rest-principles-descriptive-uris</link>
			</item>
	<item>
		<title>REST Principles: Hypermedia and HATEOAS (6 of 8)</title>
		<description><![CDATA[Fielding (2000, p. 82) describes a way of using hypermedia as the engine of application state (HATEOAS). This concept requires services to outline workflows using hyperlinks, and therefore gains the advantage of being able to expose distributed resources. HATEOAS also implies that a client should be able to access every permissible resource in a service [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/rest-principles-hypermedia-and-hateoas</link>
			</item>
	<item>
		<title>REST Principles: Safety and Idempotence (7 of 8)</title>
		<description><![CDATA[These two concepts are used to define method behaviours: safe methods do not modify state, whereas idempotent methods can, but will not cause additional changes after their initial execution. Most of HTTP's methods fall into one or both of these groups, therefore allowing developers to design conventional services which expose predictable interfaces to clients. It [...]]]></description>
		<link>http://www.lawrence.wagerfield.com/rest-principles-safety-and-idempotence</link>
			</item>
</channel>
</rss>

