I am using my minimum viable API operations definition tool to continue profiling the API sector, this time to size up the Slack API community. Slack is kind of a darling of the API space, so it kind of seem silly to profile them, but profiling those who are doing this API think right, is what API Evangelist all about--whether I follow the hype or not.
Using my minimum viable API definition, I went through the Slack API portal looking for what I'd consider to be the essential building blocks that any modern API platform should have.
| API Overview | ||
| Name: |  |
Slack API |
| Description: | |
All of our APIs can be used alone or in conjunction with each other to build many different kinds of Slack apps. Whether you're looking to build an official Slack app for your service, or you just want to build a custom integration for your team, we can help you get started! |
| Image: | |
https://a.slack-edge.com/ae57/img/slack_api_logo.png |
| API URL(s) | ||
| API Portal: | |
https://api.slack.com/ |
| API Base URL: | |
https://slack.com/api/ |
| Onboarding | ||
| Getting Started: | |
https://api.slack.com/slack-apps |
| Registration: | |
https://slackhq.typeform.com/to/kOHQvo |
| Documentation: | |
https://api.slack.com/rtm |
| Code: | |
https://api.slack.com/community |
| Operations | ||
| Road Map: | |
https://api.slack.com/roadmap |
| Change Log: | |
https://api.slack.com/changelog |
| Pricing: |  |
You should be at least sharing some rate limits, acceptable uses, and other pricing and access related information. |
| Terms of Service: | |
https://slack.com/terms-of-service/api |
| Definitions | ||
| OpenAPI Spec: |  |
A machine readable OpenAPI Specification for an API is fast becoming an essential element of API operations. |
| API Blueprint: | |
A machine readable API Blueprint for an API is fast becoming an essential element of API operations. |
| Postman Collection: | |
A machine readable Postman Colelction for an API is fast becoming an essential element of API operations. |
| Communications | ||
| Github Org / User: | |
https://github.com/slackhq |
| Twitter Account: | |
https://twitter.com/slackapi |
| Blog: | |
https://medium.com/slack-developer-blog |
| Blog RSS: | |
https://medium.com/feed/slack-developer-blog |
| Support Page: | |
https://api.slack.com/docs/support |
| Contact Info | ||
| Contact Name: | |
Slack |
| Contact Email: | |
https://apievangelists.slack.com/help/requests/new |
Performing better than the review of the i.Materialise 3D printing API that I conducted the other day, Slack checks off all but one of the essential building blocks-everything except for pricing. The only other area(s) that I find deficient, is when it comes to machine readable API definitions like OpenAPI Spec and Postman Collections. These aren't required for success, but they can sure go a long ways in helping developers on-board from documentation, to generating code, and tooling that will be needed for integration.
I'm assuming Slack hasn't generated OpenAPI Specs because they have a more XML-RPC design, which I think many folks assume can't be documented in this way. While it doesn't lend itself to more easily being documented with OpenAPI Spec, I found some simple little hacks that make it doable, allowing you to also document even XML-RPC designs. Having some OpenAPI Specs and Postman Collections would make the API more accessible for people looking to play with.
Anyways, I just wanted to test out the minimum viable API operations tool on another API. I am trying to profile several APIs in this way each week, helping the number of APIs I am monitoring grow, while also encouraging other API providers to follow Slack's lead.
