Pragmatic API

Exploring the world of Web APIs, REST, and BDD.

BDD for APIs Talk at APIStrat SF 2013

- - posted in Testing Automation

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. I have a theory that many API developers use this methodology for functional/acceptance testing, but just aren’t talking about it. Presenting on this topic gave me an opportunity to meet folks from a variety of industries who all agreed this is a very effective approach for giving APIs a business language for testing.

Extend Your CRUD HTTP API With Sub-resources

- - posted in Architecture

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.

REST Roadmap - API Hypermedia for Permissions Patterns

- - posted in Architecture

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. We’ll focus completely on the notion of how to use Hypermedia concepts to provide security context to our users without creating an arbitrary security construct.

#API Makers/consumers: Do You Sometimes Feel Like No One Really Gets You?

- - posted in Culture

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. Our RESTful API provides partners and developers and opportunity to monetize their application development by utilizing our marketplace platform.”

…“{crickets chirping}”…

API Slides and Retros Collected From Twitter #apistrat #NYC 2013

- - posted in Conferences

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. APIStrat

RESTful Patterns for the HEAD Verb

- - posted in Architecture

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.

BDD / ATDD for Your Agile REST API

- - posted in Testing Automation

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.

REST Roadmap - Upgrading in the Richardson Maturity Model

- - posted in Architecture

REST Roadmap Series

I’d like to kick off my new blog with a series I’m calling, “REST Roadmap”. The idea is to put together a series of basic changes to the typical API which will ensure future success. The first installment is around getting a feel for what REST really is via the Richardson Maturity Model. In my experience, most organizations have made some progress, intentionally or inadvertently, in this regard, and are starting at around Level 1 of RMM.