Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

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

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

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.

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

Topics:
api ,integration ,api design ,amazon groups

Published at DZone with permission of Kin Lane, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

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

{{ parent.tldr }}

{{ parent.urlSource.name }}