https://www.howarddierking.com/tags/apis/ Recent content in APIs on howarddierking.com Hugo -- gohugo.io Tue, 26 Jun 2018 00:00:00 +0000 https://www.howarddierking.com/2018/06/26/your-web-api-is-not-the-www/ Tue, 26 Jun 2018 00:00:00 +0000 https://www.howarddierking.com/2018/06/26/your-web-api-is-not-the-www/ One of the most commonly-implored techniques that I’ve heard by the REST faithful to shut down any questioning of the faith is what I’ll call an “appeal to the WWW”. There are variations, but they all tend to sound something like the following (I’ve added the snarky rhetorical phrasing because that’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… https://www.howarddierking.com/2018/04/02/a-question-on-aggregate-apis-and-microservices/ Mon, 02 Apr 2018 00:00:00 +0000 https://www.howarddierking.com/2018/04/02/a-question-on-aggregate-apis-and-microservices/ I received the following question from one of our service teams last week and thought it was likely the type of issue that a lot of you are dealing with (or have solved) in our current world of “microservice all the thingz!” The question went something like this: For a current (or future) transactional API endpoint (for example CREATE [entity]]), with the move to micro services do you think (or know) that the API will still be at the highest level as it is today and behind the scenes any data stored within a micro service would just be taken care of in the ‘aggregate’ API, OR Is it the case where each micro service supporting its data would provide their own endpoints (whereby the data points are exploded over a wider distance than previously) where a consumer of such end points to achieve something like a CREATE entry transaction would have to interact with as many endpoints as is necessary. https://www.howarddierking.com/2017/05/16/an-api-by-any-other-version/ Tue, 16 May 2017 00:00:00 +0000 https://www.howarddierking.com/2017/05/16/an-api-by-any-other-version/ “A rose by any other name would smell as sweet” I’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’m always interested in hearing yours. https://www.howarddierking.com/2017/05/04/thoughts-on-a-next-generation-api-gateway/ Thu, 04 May 2017 00:00:00 +0000 https://www.howarddierking.com/2017/05/04/thoughts-on-a-next-generation-api-gateway/ Over the last two years, I’ve had the opportunity to look at a number of different API Gateway products as well as participate in the design and development of a fit for purpose gateway service for my company. Through these opportunities, I have landed on a conclusion about the current API Gateway landscape and a vision for the future of API Gateways. First, on the state of API Gateways today, I have a simple conclusion: https://www.howarddierking.com/2016/11/14/linked-data-and-mutations/ Mon, 14 Nov 2016 00:00:00 +0000 https://www.howarddierking.com/2016/11/14/linked-data-and-mutations/ I’ve spent much of the last couple years thinking about linked data and what that can mean for Web APIs. Whenever I’ve given a talk on the subject, there are generally 2 questions that get asked. The first is: what are the practical benefits of applying linked data principles such as globally scoped names, RDF, and linking to published vocabularies? For these questions, some answers are more clear (e.g. globally scoped names and a directed graph data model) while others are not (e. https://www.howarddierking.com/2016/11/04/service-ownership-and-linked-data/ Fri, 04 Nov 2016 00:00:00 +0000 https://www.howarddierking.com/2016/11/04/service-ownership-and-linked-data/ As large technology companies transition to services and APIs, there will inevitably be quite a bit of debate around what data a service “owns” (and related: how to stop another service from owning that data), what document schemas should be supported, how to create and expose Swagger documents, and so on. As I’ve observed and participated in many of these kinds of discussions, I am convinced that while none of these discussions are fundamentally bad, they are all secondary to a well thought-out data model based on a directed graph. https://www.howarddierking.com/2016/10/15/a-linked-data-overview-for-web-api-developers/ Sat, 15 Oct 2016 00:00:00 +0000 https://www.howarddierking.com/2016/10/15/a-linked-data-overview-for-web-api-developers/ For a while now, I’ve held the belief that the biggest reason people get the whole “REST" 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. https://www.howarddierking.com/2016/10/10/reading-list-web-apis-rest-linked-data/ Mon, 10 Oct 2016 00:00:00 +0000 https://www.howarddierking.com/2016/10/10/reading-list-web-apis-rest-linked-data/ In response to my recent post on Swagger and REST, I was asked the following on Twitter: @howard_dierking Trying to dig deeper into the philosophy of API specs. Got recommended reading beyond your links? — Aram Zucker-Scharff (@Chronotope) October 11, 2016 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’ve put a few canonical Web documents on here, it’s nearly impossible to go back through and chronicle every blog post and article that has shaped my thinking. https://www.howarddierking.com/2016/10/07/swagger-ain-t-rest-is-that-ok/ Fri, 07 Oct 2016 00:00:00 +0000 https://www.howarddierking.com/2016/10/07/swagger-ain-t-rest-is-that-ok/ If you’ve spent much time with me, you’ve undoubtedly heard me ramble on at length about linked data. And in those conversations, you’ve likely heard me say something to the effect of “linked data is REST”. However, I haven’t really spent much time talking about REST by itself - especially considering the amount of importance heaped on it by proponents of the “API Economy”. I’ve focused my attentions elsewhere primarily because as an architectural style, REST isn’t something that a team can just go and implement. https://www.howarddierking.com/2016/09/15/there-is-no-rest-api/ Thu, 15 Sep 2016 00:00:00 +0000 https://www.howarddierking.com/2016/09/15/there-is-no-rest-api/ I’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’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’t describe APIs. REST describes the architectural characteristics of an entire system, which includes all of the different components of that system. https://www.howarddierking.com/2016/04/22/a-question-on-api-design-and-documentation/ Fri, 22 Apr 2016 00:00:00 +0000 https://www.howarddierking.com/2016/04/22/a-question-on-api-design-and-documentation/ One of the projects that my team owns is the Concur Developer Center. Among other information, it houses the documentation for Concur’s Web APIs. The documentation for the more recent API versions uses Swagger and until recently was generated by reflecting over the .NET API code. There were a bunch of problems that resulted from this approach as I’ll describe in a second. But there’s also some interesting trade-offs about the kind of APIs you get by focusing on service contracts as your primary design artifact. https://www.howarddierking.com/2015/05/24/on-api-gateways/ Sun, 24 May 2015 00:00:00 +0000 https://www.howarddierking.com/2015/05/24/on-api-gateways/ Do you or your company build Web APIs and, if so, do you use an API gateway to broker traffic between your customers and your products? In this post, I want to tell you a little about our experience with this class of products and add a little of my opinion, but if you’re using an API gateway, I want to hear about your experience - the good and the bad. https://www.howarddierking.com/2014/03/26/designing-evolvable-web-apis-with-asp-net-is-now-available/ Wed, 26 Mar 2014 00:00:00 +0000 https://www.howarddierking.com/2014/03/26/designing-evolvable-web-apis-with-asp-net-is-now-available/ Although it actually became available last week, I hadn’t blogged about it yet, so correcting that oversight here… 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. https://www.howarddierking.com/2013/09/23/the-secret-to-restful-services-is-restful-clients/ Mon, 23 Sep 2013 00:00:00 +0000 https://www.howarddierking.com/2013/09/23/the-secret-to-restful-services-is-restful-clients/ 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. https://www.howarddierking.com/2013/09/12/versioning-restful-services-v2/ Thu, 12 Sep 2013 00:00:00 +0000 https://www.howarddierking.com/2013/09/12/versioning-restful-services-v2/ 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. https://www.howarddierking.com/2012/11/09/versioning-restful-services/ Fri, 09 Nov 2012 00:00:00 +0000 https://www.howarddierking.com/2012/11/09/versioning-restful-services/ 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).