<?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>RFC 2616 &#8211; API UX</title>
	<atom:link href="/tag/rfc-2616/feed/" rel="self" type="application/rss+xml" />
	<link>/</link>
	<description>Everything about API User Experience</description>
	<lastBuildDate>Tue, 11 Jun 2013 16:14:27 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.8.6</generator>
	<item>
		<title>The Accept Header: A Quick Primer</title>
		<link>/2013/06/11/accept-header-quick-primer/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=accept-header-quick-primer</link>
					<comments>/2013/06/11/accept-header-quick-primer/#comments</comments>
		
		<dc:creator><![CDATA[Michael Pratt]]></dc:creator>
		<pubDate>Tue, 11 Jun 2013 16:00:44 +0000</pubDate>
				<category><![CDATA[Opinion]]></category>
		<category><![CDATA[Accept]]></category>
		<category><![CDATA[API]]></category>
		<category><![CDATA[APIUX]]></category>
		<category><![CDATA[header]]></category>
		<category><![CDATA[HTTP]]></category>
		<category><![CDATA[JSON]]></category>
		<category><![CDATA[RFC 2616]]></category>
		<category><![CDATA[XML]]></category>
		<guid isPermaLink="false">/?p=480</guid>

					<description><![CDATA[Why should you use the Accept header? So many APIs can simply get by with a string comparison against "application/json" or "application/xml", why is it important?]]></description>
		
					<wfw:commentRss>/2013/06/11/accept-header-quick-primer/feed/</wfw:commentRss>
			<slash:comments>5</slash:comments>
		
		
			</item>
		<item>
		<title>Implementing API Content Negotiation</title>
		<link>/2013/05/07/api-content-negotiation/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=api-content-negotiation</link>
					<comments>/2013/05/07/api-content-negotiation/#comments</comments>
		
		<dc:creator><![CDATA[Bruno Pedro]]></dc:creator>
		<pubDate>Tue, 07 May 2013 13:00:01 +0000</pubDate>
				<category><![CDATA[Opinion]]></category>
		<category><![CDATA[Accept]]></category>
		<category><![CDATA[Accept-encoding]]></category>
		<category><![CDATA[Accept-language]]></category>
		<category><![CDATA[API]]></category>
		<category><![CDATA[APIUX]]></category>
		<category><![CDATA[Content]]></category>
		<category><![CDATA[header]]></category>
		<category><![CDATA[JSON]]></category>
		<category><![CDATA[Negotiation]]></category>
		<category><![CDATA[RFC 2616]]></category>
		<category><![CDATA[UX]]></category>
		<category><![CDATA[XML]]></category>
		<guid isPermaLink="false">/?p=348</guid>

					<description><![CDATA[Content Negotiation servers two purposes: making it possible to have different versions of the same response, and letting clients specify which version they want to receive. Usually, this technique is applied when there are several types of user agents consuming the same HTTP resource but, because they have different rendering capabilities, they might ask for different content types.]]></description>
		
					<wfw:commentRss>/2013/05/07/api-content-negotiation/feed/</wfw:commentRss>
			<slash:comments>12</slash:comments>
		
		
			</item>
		<item>
		<title>2 steps to better API Error Codes</title>
		<link>/2013/03/28/2-steps-api-error-codes/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=2-steps-api-error-codes</link>
					<comments>/2013/03/28/2-steps-api-error-codes/#comments</comments>
		
		<dc:creator><![CDATA[Bruno Pedro]]></dc:creator>
		<pubDate>Thu, 28 Mar 2013 17:00:03 +0000</pubDate>
				<category><![CDATA[Opinion]]></category>
		<category><![CDATA[API]]></category>
		<category><![CDATA[code]]></category>
		<category><![CDATA[developer]]></category>
		<category><![CDATA[error]]></category>
		<category><![CDATA[HTTP]]></category>
		<category><![CDATA[integration]]></category>
		<category><![CDATA[JSON]]></category>
		<category><![CDATA[REST]]></category>
		<category><![CDATA[RFC 2616]]></category>
		<category><![CDATA[steps]]></category>
		<category><![CDATA[UX]]></category>
		<category><![CDATA[XML.protocol]]></category>
		<guid isPermaLink="false">/?p=171</guid>

					<description><![CDATA[One of the biggest difficulties developers can have when writing code that talks with an API is dealing with errors and exceptions, and translating those errors into something meaningful for their applications.]]></description>
		
					<wfw:commentRss>/2013/03/28/2-steps-api-error-codes/feed/</wfw:commentRss>
			<slash:comments>14</slash:comments>
		
		
			</item>
	</channel>
</rss>
