Over a million developers have joined DZone.

Amazon Groups Should Share More API Design Patterns

DZone's Guide to

Amazon Groups Should Share More API Design Patterns

Amazon isn't known for their RESTful APIs, which is fine, but when it comes to their lack consistency between their different APIs, there are lessons we can all learn.

· Integration Zone ·
Free Resource

How to Transform Your Business in the Digital Age: Learn how organizations are re-architecting their integration strategy with data-driven app integration for true digital transformation.

The sharing of common API design patterns is something we are really bad at in the API space. I'm not a believer that there is one API design pattern to rule them all, but I am a believer in learning from what works, consuming other people's APIs, and sharing design tips over the cubicle wall. I don't believe that everyone should be 100% REST-compliant in the crafting of their APIs, but you should be picking your head up from time to time and learning from what the rest of the world is up to, especially across the other groups within your own company.

I tend to shy away on critiquing companies on API design and prescribing any specific approach, but I can't help but point out inconsistencies in any approach when it is clear that they aren't tuning into some of the common patterns out there (especially among their own internal groups). An example of this can be found at one of the API gods, Amazon Web Services. Amazon isn't known for their RESTful APIs, which is something I can overlook, but when it comes to their lack consistency between their different APIs, I think there are lessons for all of us to learn from.

I have not hacked against all of the Amazon APIs, but here are the four distinct patterns I've seen:

  1. S3: /?{method}
  2. EC2: /?Action={method}
  3. Route 53: /2013-04-01/{methodname}
  4. Route 53 Domains: route53domains.us-east-1.amazonaws.com/ header: x-amz-target:Route53Domains_v20140515.{method}

There might be additional patterns employed over at other Amazon APIs, but these are the four that I'm exposed to in my own integrations. The presence of two separate patterns within the Route 53 team was what prompted me to write this post. While I'm not a fan of the action={method} approach, which is the most common AWS pattern I have seen used, the passing of methods as part of a custom header just seems even wackier to me. 

I do not get dogmatic about specific API design patterns, but I do think that a lack of awareness of common patterns, especially across groups within the same company, is counterproductive. I think  that Amazon has done amazing things as a pioneer in the space, forever changing how we deliver data, content, and algorithmic resources online, but I think that they would benefit from a company-wide API design campaign — something like Microsoft, Paypal, and others have done to help standardize how they design APIs across all internal groups.

Build and deploy API integrations 7x faster. Try the Cloud Elements 100% RESTful platform for 30 days free. Access your trial here.

api ,integration ,api design ,amazon groups

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}