2014 was an extremely busy year at Paypal: heading up the API Design team, in an effort to API-ify over 80% of the company’s capabilities. I only managed to get out three blog posts, all on http://APIUX.com. As I looked at revising my strategy for sharing with the community for 2015, I had to reflect on 2014. Public speaking: I attended 12 events, I think 10 of which I gave talks at.
I recently attended the API Strategy & Practices conference in San Francisco. I also attended earlier this year in New York, but this time I came as a speaker. I enjoyed the panel format in NYC so much, I decided I had to be a part of it. I wanted to bring something that I haven’t heard before at API-related conferences. I’ve blogged quite a bit in the past on the topic of BDD for APIs.
[Reposted from conquer.tech] One of the neat things about living in Austin is the tech people you get to meet. Some of the ones I have met along the way have been gracious enough to let me interview them. Today’s post is an interview I recently conducted with my friend Jason Harmon. He has always seemed to me to be one of the brightest guys I know when it comes to technologies.
When it’s time to build your web API, there’s often a tendency to build everything around data entities. CRUD-style APIs use GET/POST/PUT/DELETE to provide the same feel as SELECT/INSERT/UPDATE/DELETE in a traditional relational database. Once you work through these CRUD-based web API patterns for a while, you will find that it doesn’t always match up perfectly to your business needs. I’d like to introduce a design pattern which will add some flexibility to your CRUD-stye HTTP API, while maintaining clean semantics and easy usability.
It’s been a while since my first post in the REST Roadmap series on RMM Level 2 / verbs / HTTP status codes. I’d like to continue moving up the RMM chain, looking at Hypermedia as the Level 3, according to Martin Fowler and Leon Richardson. In the spirit of pragmatism, I’d like to tune out a lot of the chatter about media types, link formats, and the like when it comes to hypermedia for the sake of this post.
I’ve found myself explaining to lots of people what it is that I do, in working with APIs. Sure, at the office or a conference, I feel understood. However in social settings or around family, I sometimes feel like people just think I’m making this stuff up. When I try to use acronym and industry jargon filled phrases, I often just get glazed over stares and slow head nodding. “I offer a series of integration points for mobile, web, and B2B web services consumers.
I had a blast at the API Strategy and Practices Conference in NYC over the weekend. I learned things, I shared and socialized ideas, and was generally awed by the level of brainshare happening. In an effort to share this with folks who didn’t make it, I’ve collected all I could along the way, and I’m sharing it. Please send me anything I’ve missed, whether you presented it or just took better notes than me.
In the typical usage of HTTP, the GET and POST verbs seem to get the most mileage. I’ve previously covered some aspects of moving up the Richardson Maturity Model scale. Implementing the PUT and DELETE verbs is typically a step up to RMM Level 2. There are other HTTP verbs, outside of the ‘by the book’ RESTful patterns, which can prove very useful in certain situations. One of the easiest to implement verbs, with some great benefits in scaling terms, is the HEAD verb.
Part 1: http://pragmaticapi.com/2013/01/12/bdd-atdd-for-your-agile-rest-api/ I recently covered how BDD principles can provide a great touch stone for acceptance testing in REST-based API platforms. In this brief followup, I’ll show how the Cucumber-JVM framework provides all of the same functionality that we saw in .NET’s SpecFlow, using the Groovy programming language. Code for this example can be found on Github. This should provide you with a working example of BDD testing the Twitter API using Cucumber-JVM, Gradle, and Groovy.
In any system architecture, a multi-tiered testing strategy is critical. Much of this work is typically behind the scenes in development teams, often following TDD-oriented practices. In agile terms, stakeholders and product owners often never see or grasp what’s being tested. Within the unit testing and integration testing tiers, this tends to make sense. However Behavioral Driven Development (aka Acceptance Test Driven Development) begins with acceptance criteria definition and finishes with the acceptance of a story, providing engagement for all members of an agile team from start to finish.
Template by Bootstrapious. Ported to Hugo by DevCows.
