Building an API can happen in a matter of minutes. But there is a big difference between whipping up an API, and crafting one that is secure, reliable and meets the user’s expectations. In this article we looks at six common mistakes that arise from APIs that weren’t made with enough care.
- Articles (29)
- APIs (1)
- Mashups (0)
- SDKs (1)
- Libraries (0)
- Sample Source Code (4)
- Followers (2)
- Developers (0)
API Education Articles
The following is a list of ProgrammableWeb articles that matched your search term. On an nearly 24/7 basis, ProgrammableWeb publishes new articles ranging from news to opinion to tutorials for both developers and API providers. All of our articles are categorized in such a way that you can find your way to related articles, APIs, SDKs, Libraries, Frameworks, Tutorials and Sample Source Code. If you have an interest in contributing any of the aforementioned content to ProgrammableWeb, be sure to read our guidelines for such contributions.
Back in 2005, when I bore witness to the debut of the first two Web APIs (Google Maps and Flickr) while working as a journalist for CNET, I knew something big was about to happen. To this day, it is still one of the most dramatic tipping points our industry has ever seen.
API documentation, as we all know, is rarely comprehensive and almost never up-to-date. An alternative way to get to know an API is by intercepting API calls from a mobile app and examining how they work. Here Jan Schwoebel over at his blog will show you how you can easily do that for iOS apps.
A good API is the secret to being able to test earlier, which means finding problems earlier in the software process. Perhaps earlier enough to prevent the delays, certainly earlier enough to save time. If you want to test earlier and be more effective, this is the place to start.
The best workflows direct customers through business processes, guiding them along each step they need to take to reach their goals. They also give developers good starting points for testing. But how can API testing workflows help teams figure out where to start, and know when they're done?
This is the final part of our API Testing series. In this article we will talk about what's coming up in the near future that will change how we test and deliver new APIs. Included are looks at the possible effects of newer architectural styles such as GraphQL and gRPC, and new tooling.
In order for APIs to deliver on a myriad of benefits and objectives, organizations must design them with scale in mind. However, the need to build high-performing APIs that scale with the business ecosystem is pressuring many development teams to build APIs that may be restricting business growth.
Our series on getting the most ROI out of your API has looked at the business and technical decisions to make when building your API strategy. We've also made decisions around how to engage with developers and build a developer community. A key aspect to this involves creating a developer portal.
Now that your API has been published and external developers are beginning to consume it, our focus shifts again towards a balance between business and technical issues. In this part of the series we take a look at how a business can leverage the technical API to grow a developer community?
At this point in your API journey, you have made a number of business decisions and a couple of technical ones. Now, several crucial decisions need to be made around security. Securing an API is an often neglected task, yet doing so is at the heart of an effective API strategy.