<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>REST on howarddierking.com</title>
    <link>https://www.howarddierking.com/tags/rest/</link>
    <description>Recent content in REST on howarddierking.com</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 26 Jun 2018 00:00:00 +0000</lastBuildDate><atom:link href="https://www.howarddierking.com/tags/rest/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Your Web API is Not the WWW</title>
      <link>https://www.howarddierking.com/2018/06/26/your-web-api-is-not-the-www/</link>
      <pubDate>Tue, 26 Jun 2018 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2018/06/26/your-web-api-is-not-the-www/</guid>
      <description>One of the most commonly-implored techniques that I&amp;rsquo;ve heard by the REST faithful to shut down any questioning of the faith is what I&amp;rsquo;ll call an &amp;ldquo;appeal to the WWW&amp;rdquo;. There are variations, but they all tend to sound something like the following (I&amp;rsquo;ve added the snarky rhetorical phrasing because that&amp;rsquo;s what all variations sound like in my head):
If only there was some super-successful reference implementation of REST that we could just follow&amp;hellip;</description>
    </item>
    
    <item>
      <title>An API by Any Other Version</title>
      <link>https://www.howarddierking.com/2017/05/16/an-api-by-any-other-version/</link>
      <pubDate>Tue, 16 May 2017 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2017/05/16/an-api-by-any-other-version/</guid>
      <description>&amp;ldquo;A rose by any other name would smell as sweet&amp;rdquo;
I&amp;rsquo;ve written and spoken on the topic of API versioning numerous times over the last several years - particularly in regard to RESTful APIs. However, as APIs become more mainstream and the number of scenarios and expectations grows, it seems like it may be time for another turn of the crank in thinking about API versions. As always, these are just my thoughts, and I&amp;rsquo;m always interested in hearing yours.</description>
    </item>
    
    <item>
      <title>A Linked Data Overview for Web API Developers</title>
      <link>https://www.howarddierking.com/2016/10/15/a-linked-data-overview-for-web-api-developers/</link>
      <pubDate>Sat, 15 Oct 2016 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2016/10/15/a-linked-data-overview-for-web-api-developers/</guid>
      <description>For a while now, I’ve held the belief that the biggest reason people get the whole “REST&amp;quot; thing wrong is because they are looking at Roy Fielding’s doctoral dissertation – the paper that coins the term “REST” - as a prescription for how to design APIs.
There are 2 things wrong here that I think explain the current state of the API world when it comes to REST. First, is the idea that the terms and descriptions in the paper can be exclusively applied to the server.</description>
    </item>
    
    <item>
      <title>Reading List: Web APIs, REST, Linked Data</title>
      <link>https://www.howarddierking.com/2016/10/10/reading-list-web-apis-rest-linked-data/</link>
      <pubDate>Mon, 10 Oct 2016 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2016/10/10/reading-list-web-apis-rest-linked-data/</guid>
      <description>In response to my recent post on Swagger and REST, I was asked the following on Twitter:
Rather than a Twitter stream of references, I thought I would just consolidate my resource list here. Note that for the most part, this list is limited to books. While I&amp;rsquo;ve put a few canonical Web documents on here, it&amp;rsquo;s nearly impossible to go back through and chronicle every blog post and article that has shaped my thinking.</description>
    </item>
    
    <item>
      <title>Swagger Ain&#39;t REST - is that OK?</title>
      <link>https://www.howarddierking.com/2016/10/07/swagger-ain-t-rest-is-that-ok/</link>
      <pubDate>Fri, 07 Oct 2016 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2016/10/07/swagger-ain-t-rest-is-that-ok/</guid>
      <description>If you&amp;rsquo;ve spent much time with me, you&amp;rsquo;ve undoubtedly heard me ramble on at length about linked data. And in those conversations, you&amp;rsquo;ve likely heard me say something to the effect of &amp;ldquo;linked data is REST&amp;rdquo;. However, I haven&amp;rsquo;t really spent much time talking about REST by itself - especially considering the amount of importance heaped on it by proponents of the &amp;ldquo;API Economy&amp;rdquo;. I&amp;rsquo;ve focused my attentions elsewhere primarily because as an architectural style, REST isn&amp;rsquo;t something that a team can just go and implement.</description>
    </item>
    
    <item>
      <title>There is No REST API</title>
      <link>https://www.howarddierking.com/2016/09/15/there-is-no-rest-api/</link>
      <pubDate>Thu, 15 Sep 2016 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2016/09/15/there-is-no-rest-api/</guid>
      <description>I&amp;rsquo;ve spent some time talking with my teams recently about REST from the perspective of an API, and also how APIs built through the lens of technologies like Swagger go against some of the most important principles of REST. As I&amp;rsquo;ve reflected more over conversations, there is one even more fundamental thing that tends to get lost in the conversation. And that is that REST doesn&amp;rsquo;t describe APIs. REST describes the architectural characteristics of an entire system, which includes all of the different components of that system.</description>
    </item>
    
    <item>
      <title>Designing Evolvable Web APIs with ASP.NET is Now Available!</title>
      <link>https://www.howarddierking.com/2014/03/26/designing-evolvable-web-apis-with-asp-net-is-now-available/</link>
      <pubDate>Wed, 26 Mar 2014 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2014/03/26/designing-evolvable-web-apis-with-asp-net-is-now-available/</guid>
      <description>Although it actually became available last week, I hadn&amp;rsquo;t blogged about it yet, so correcting that oversight here&amp;hellip;
After over a year of development, what started as an abstract idea has finally come into being. The idea, while abstarct, was not simple by any means - we wanted to write a book that covered not just the internal workings of the ASP.NET Web API framework, but also how to use it to build systems that would be reliable and evolvable over a long period of time.</description>
    </item>
    
    <item>
      <title>The Secret to RESTful Services is RESTful Clients</title>
      <link>https://www.howarddierking.com/2013/09/23/the-secret-to-restful-services-is-restful-clients/</link>
      <pubDate>Mon, 23 Sep 2013 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2013/09/23/the-secret-to-restful-services-is-restful-clients/</guid>
      <description>I’m sitting in the airport waiting to head back to Seattle after several great days at RestFest here in Greenville, SC. Many thanks to Mike Amundsen and Benjamin Young for being such gracious hosts. I’m pretty tired at the moment, but I had a couple takeaways that I wanted to get out there – mainly so that if I forget, I have a reference point to return to.
First, there were a few technologies that caught my attention that I want to spend some time going deeper on.</description>
    </item>
    
    <item>
      <title>Versioning RESTful Services v2</title>
      <link>https://www.howarddierking.com/2013/09/12/versioning-restful-services-v2/</link>
      <pubDate>Thu, 12 Sep 2013 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2013/09/12/versioning-restful-services-v2/</guid>
      <description>See what I just did there? ^^
Done :)
Since publishing both the REST Fundamentals course as well as my previous post on RESTful API versioning, I’ve had the opportunity to think more about versioning in practice as I’ve been a part of designing the next major revision to the NuGet API (v3). This has been very helpful for a couple of reasons, but the most important one is that NuGet is a real application that has both non-trivial scale requirements and a number of different clients – many of which are not controlled by the NuGet core team.</description>
    </item>
    
    <item>
      <title>Versioning RESTful Services</title>
      <link>https://www.howarddierking.com/2012/11/09/versioning-restful-services/</link>
      <pubDate>Fri, 09 Nov 2012 00:00:00 +0000</pubDate>
      
      <guid>https://www.howarddierking.com/2012/11/09/versioning-restful-services/</guid>
      <description>I’ve talked about this in various venues and also cover it in my Pluralsight REST Fundamentals course, but the topic of how to version RESTful services has been popping up a bunch recently on some of the ASP.NET Web API discussion lists, and my friend Daniel Roth asked if I could serialize some of that presentation content into a blog post – so here goes.
First, note that while the focus here is on RESTful services and not just HTTP services, the same principles can potentially apply to HTTP services that are not fully RESTful (for example, HTTP services that do not use hypermedia as a state transition mechanism).</description>
    </item>
    
  </channel>
</rss>
