DZone
Integration Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Integration Zone > Pandora, Target, and Considering How Public to Be With Your API Operations

Pandora, Target, and Considering How Public to Be With Your API Operations

Even with keeping the lock and key on our API resources, we can still be public with our API operations. There are many positive reasons for doing so.

Kin Lane user avatar by
Kin Lane
·
Nov. 24, 16 · Integration Zone · Opinion
Like (1)
Save
Tweet
2.88K Views

Join the DZone community and get the full member experience.

Join For Free

I am reworking the API Evangelist developer area and shifting most of my content to be available as YAML and JSON data on the GitHub repositories that drive my network of sites. I'm doing this partly because I am not in the business of managing and growing an API community and because there are some really badly behaved people out there that I'm just not really interested in having keys to my internal network. I am happy to open up read-only access to my work publicly and write capabilities to my trusted partners, but having self-service access to my server(s) just isn't fun in the current online climate. 

I get it when folks want to keep their valuable data, content, and algorithm under lock and key, and require developers to build a relationship before they get access or increased levels of consumption. However, this hasn't always been the tune I've whistled. There are plenty of examples of me telling API providers to provide self-service access to their resources in the past (well, we've f*cked that off with our bad behavior as API consumers). It's not that the concept won't work; it's just that it won't work with the number of...people...on the web these days, it just isn't a good idea.

Even with keeping the lock and key on our API resources, we can still be public with our API operations. There are many positive reasons for doing so. SEO is probably the first. I mean, how are people going to find your APIs if they can't Google for them? Providing information to the press and making the resources that support your APIs self-service can reduce the workload when you do give people access. Some examples of this can be found when looking at the Target versus Pandora developer programs; both required approval to get access, but Target is much more open than Pandora with their overall story.

Target really doesn't have that much more than Pandora does, but they have a blog and link to their GitHub, and of course their jobs page. I'm still going to publish the documentation for my own APIs and go further than Target has, but I have to give them credit for being at least a little more creative and public than Pandora. Like I said, I won't be pushing back on providers when they do not have self-service public access to their API resources anymore, but I will be encouraging y'all to be creative when thinking about the public presence of your operations and engaging in some meaningful storytelling via a publicly available portal.

API

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

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Open Source Monitoring and Metrics Landscape
  • 10 Programming Habits a Web Developer Should Embrace
  • Progressive Web Apps vs Native Apps: Differences and Similarities
  • Migrating Legacy Applications and Services to Low Code

Comments

Integration Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo