<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Robert LaThanh &#187; portmanteau</title>
	<atom:link href="http://robertlathanh.com/category/portmanteau/feed/" rel="self" type="application/rss+xml" />
	<link>http://robertlathanh.com</link>
	<description></description>
	<lastBuildDate>Tue, 28 Feb 2012 17:52:27 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>bebooper</title>
		<link>http://robertlathanh.com/2010/10/bebooper/</link>
		<comments>http://robertlathanh.com/2010/10/bebooper/#comments</comments>
		<pubDate>Tue, 19 Oct 2010 19:00:42 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[portmanteau]]></category>

		<guid isPermaLink="false">http://robertlathanh.com/?p=110</guid>
		<description><![CDATA[bebooper [bee-boo-per]: beep + boop + computer -noun Those things in movies that look like computers, but beep or boop every time something is clicked on, whir whenever there&#8217;s a progress bar, or ever show an &#8220;ACCESS DENIED&#8221; message in &#8230; <a href="http://robertlathanh.com/2010/10/bebooper/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<h4><strong><em>bebooper</em></strong> [bee-boo-per]: <span style="text-decoration: underline;">be</span>ep + <span style="text-decoration: underline;">boop</span> + comput<span style="text-decoration: underline;">er</span></h4>
<p>-noun</p>
<ol>
<li>Those things in movies that look like computers, but beep or boop every time something is clicked on, whir whenever there&#8217;s a progress bar, or ever show an &#8220;ACCESS DENIED&#8221; message in a 36 pt. or greater font size. These devices are often also likely to be able to <a href="http://www.youtube.com/watch?v=Vxq9yj2pVWk" target="_blank">enhance</a> images, interpolating up to 729 pixels where there were originally only nine.</li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://robertlathanh.com/2010/10/bebooper/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>WREST (Website REST)</title>
		<link>http://robertlathanh.com/2009/10/wrest-website-rest/</link>
		<comments>http://robertlathanh.com/2009/10/wrest-website-rest/#comments</comments>
		<pubDate>Thu, 15 Oct 2009 05:10:27 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[Web Technology]]></category>
		<category><![CDATA[portmanteau]]></category>

		<guid isPermaLink="false">http://robertlathanh.com/?p=86</guid>
		<description><![CDATA[WREST [rest] = Website + REST -noun A RESTful API service that is made available to its own website. The distinguishing behavior from a regular RESTful API is that calls coming from the client are identified the same way as &#8230; <a href="http://robertlathanh.com/2009/10/wrest-website-rest/">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p><strong><em>WREST</em></strong> [rest] = Website + REST</p>
<p>-noun</p>
<ol>
<li>A RESTful API service that is made available to its own website. The distinguishing behavior from a regular RESTful API is that calls coming from the client are identified the same way as other calls made by the client&#8217;s browser (viz., the client&#8217;s cookie(s)) rather than by API keys and secrets/signatures.</li>
</ol>
<p>I&#8217;m currently working on a service that has both a website (usable by the general public), and a <a href="http://en.wikipedia.org/wiki/REST">REST</a>ful API (currently used by our iPhone app, and later usable by partners). A Flash component of the website also uses the RESTful API when it needs needs data from the server. And while partners will need to obtain an API key, get user approval to make calls on their behalf, and sign calls, it would not be appropriate to expect the same of the Flash component.</p>
<p>So, I made some of the RESTful API calls available in a way such that the client can be identified by cookies instead of an API authorization token.</p>
<p>This results in the service having four classes of HTTP calls:<span id="more-86"></span></p>
<ol>
<li><strong>Regular website calls</strong> &#8211; calls made by a client&#8217;s web browser, where the response is HTML or a resource such as a JPG, CSS, or JS file. Clients are identified by their cookie(s)</li>
<li><strong>REST</strong> &#8211; calls to RESTful API methods made by non-web-based client or via a 3rd-party. Every call must include the caller&#8217;s Application API key and be signed with their API secret. The user the call is being made on behalf of (if applicable) is identified by an authorization token included as a request parameter. For us, the response is XML (and for others it may be another data interchange format such as JSON).</li>
<li><strong>AJAX</strong> &#8211; calls made by a client&#8217;s web browser (typically asynchronously) where the response is XML but the call is not an API call (viz., not RESTful). They are specifically designed to serve website needs, and likely characteristics are that they:
<ul>
<li>include HTML fragments to be included in the page dynamically, or</li>
<li>include other data or parameters specifically to dynamically alter a portion of the current web page.</li>
</ul>
</li>
<li><strong>WREST</strong> &#8211; RESTful API calls made by the website. For us, this is primarily used by the Flash component(s). The client is identified using cookies and the session like the website, but respond purely with structured data (in XML) like the &#8216;REST API&#8217;. The controllers that serve these calls are generally the same controllers used by the REST API servlet. A good rule of thumb is that: if the call would not make a good (REST) API call, it is probably an AJAX call and not a WREST call. Thus, WREST is generally a subset of REST.</li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://robertlathanh.com/2009/10/wrest-website-rest/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>haircro</title>
		<link>http://robertlathanh.com/2009/10/haircro/</link>
		<comments>http://robertlathanh.com/2009/10/haircro/#comments</comments>
		<pubDate>Sun, 11 Oct 2009 02:44:43 +0000</pubDate>
		<dc:creator>Robert</dc:creator>
				<category><![CDATA[portmanteau]]></category>

		<guid isPermaLink="false">http://robertlathanh.com/?p=74</guid>
		<description><![CDATA[haircro [hair-kroh]: hair + Velcro -noun When hair is cut very short (using, say, #2 on clippers), the hair holds hoodie hoods on like it&#8217;s Velcro &#8212; but it&#8217;s hair! ﻿]]></description>
			<content:encoded><![CDATA[<h4><strong><em>haircro</em></strong> [<strong>hair</strong>-kroh]: hair + Velcro</h4>
<p>-noun</p>
<ol>
<li>When hair is cut very short (using, say, #2 on clippers), the hair holds hoodie hoods on like it&#8217;s Velcro &#8212; but it&#8217;s hair!</li>
</ol>
<div id="_mcePaste" style="position: absolute; left: -10000px; top: 0px; width: 1px; height: 1px; overflow-x: hidden; overflow-y: hidden;">﻿</div>
]]></content:encoded>
			<wfw:commentRss>http://robertlathanh.com/2009/10/haircro/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

