Download to read offline
Uploaded byScribe Software Corp.
7 Traits of a Great API
The document is a webinar presentation by Peter Chase from Scribe Software, focusing on data integration in the API economy. It includes housekeeping notes about attending the webinar, discussing API standards, performance, security, and user experience. Additionally, resources like a white paper and a link for API assessment are provided for further information.
Technologyâ—¦
More Related Content
![Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]](https://cdn.slidesharecdn.com/ss_thumbnails/codedagentsdeck-251215155422-5497c599-thumbnail.jpg?width=640&height=640&fit=bounds)
7 Traits of a Great API
- 1. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. Presenter: Peter Chase - Founder and Executive Vice President, Scribe
- 2. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 2 Housekeeping • The recording will be available to you 2 hrs. after the webinar • Icons at the bottom of the slide deck allow you to: ◦ Adjust sound ◦ Participate in Q&A ◦ Contribute to the discussion on twitter @scribesoft –#DataIntegration & let us know we are #AWESOME! ◦ Download a copy of the slide deck ◦ Get to know the speakers • You can ask questions at anytime but we will answer all questions after the presentation is over.
- 3. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. Peter Chase Executive VP Business Development & Founder, Scribe @peterrchase peter.chase@scribesoft.com
- 4. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 4 Background • API Economy is driving interest in the subject • Data Integration Focused • Based on our experience with hundreds of APIs and tens of thousands of integration use cases
- 5. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 5 Open Standards vs Proprietary Architecture
- 6. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 6 Change Data Capture
- 7. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 7 Performance and Efficiency
- 8. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. Metadata Driven
- 9. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 9 Consistency and obviousness
- 10. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 10 Security
- 11. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 11 User Experience
- 12. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 12
- 13. @scribesoft CONFIDENTIAL | ©2015 Scribe Software Corporation. All rights reserved. 13 Download the White Paper www.scribesoft.com Email: isv@scribesoft.com Thank You For a more detailed API Assessment http://www.scribesoft.com/saas/partner/api-assessment-options/
Editor's Notes
- #2 Welcome to today’s webinar – 7 Traits of a world-class API and how to get the most out of it.
- #5Â In the interest of time I will be moving along pretty quickly. Some of the traits I will spend just a minute on while others I will dig in with a bit more detail.
- #6 This is the most obvious of the seven traits but building your API on an open standard makes it much easier to work with and enables you to take full advantage of the framework to deliver maximum functionality. SOAP and REST are the two most common standard frameworks we see today, with a strong trend towards REST…70% plus of new APIs we see being developed are REST.
- #7 Change is the driving force of integration. A critical function within the SaaS application is the ability to identify the small changes to data. So that only data that has changed since the data source was last integrated can be identified and processed. At a minimum, for all objects a SaaS provider should allow access to a date/time stamp, along with an “updated by” field that identifies the user(s) who made modifications. Integration processes can then periodically poll for all records that have been updated since the last time the record was modified. Designating the user enables the SaaS provider to ignore changes that another application made, which avoids creating an endless loop of integration updates. While the date/time stamp method is straightforward, it does have two major limitations. First, it fails to identify when records are deleted, since those records will no longer show up in any query. And second, polling approaches tax your server and can be highly inefficient. One approach to solving this issue is implementing a change publishing capability where users can identify changes they want to capture and then the API publishes those changes to a secure Web services endpoint as they happen.
- #8 There are two types of performance that customers will push you on…the first is high throughput (pushing large amounts of data through your API in short time windows) and the second is low latency (lightning fast response time for individual records or requests). The best way to try to deliver all of this is to document your customers’ real-world use cases and their performance requirements. Those use cases then serve as the benchmark for the performance standards you’ll need to achieve. API calls are expensive from a performance perspective. Reducing the number of calls is an important way to address performance and efficiency. Some key ways to accomplish this are:  Bulk support - This refers to enabling users to request or pass bulk arrays of data through the API. The SaaS provider can then process these requests back on its servers in highly scalable and performant manner. Implementing bulk import or export capabilities can yield record processing speeds that can be 10 to 100 times faster than from a transactional API. In many scenarios, where record-by-record validation isn’t required, this is a highly valuable feature. Combination operations - Facilitating combination operations such as “upserts” (updating and inserting all in one API call) enables the API to perform some of the advanced logic required for certain activities, which reduces the number of API calls. However, there is a balance to maintain here; the more customer control that are allowed related to this interaction, the more API calls may be necessary—and the time and expense required for these operations will rise accordingly. For example, a process may require information from a SaaS application prior to determining how to process a record. This run-time level conditional processing might not be achievable utilizing an upsert. Message publishing - See the “Change data capture” section above. Multi-threading - This enables a single API user to open multiple threads of interaction within the same user session, thus enabling integration processes to operate at much higher speeds. Care should be taken to ensure that the API is “thread-safe” so that separate processes do not trip over one another. Support for both batch and real-time processes – Users of the SaaS applications will have scenarios where they need to integrate large batches of data on a schedule while other use cases will require support for real-time processes. In fact, for the majority of integration scenarios, moving records in batch is easier to implement and meets the business need. While real-time integration can be a bit more complex (as it can involve more complex user workflow and dependencies), there are scenarios where real-time access is necessary and more efficient.
- #9 Your customers are likely to customize and configure the functionality and data design of your application for their particular need. In spite of this, you want to encourage developers in your ecosystem to develop solutions that can be used across many customers. Our experience shows that you should provide dynamic discovery of each customer’s metadata at run-time when you design your API. Developers can then surface those particular customizations in their tools and set-up wizards to enable customers to quickly tailor the integrated solution to their particular environment. This metadata discovery goes beyond simply providing the objects and fields in the customer’s environment; it should include the relationships between objects, data types, and other attributes (indexes, required, default or picklist values, etc.). By providing this rich metadata discovery, you enable your partner ecosystem to leverage your API to the fullest across a diverse customer base.
- #10 This is all about making it easier for those developing against your API. The API should use standard and consistent naming conventions for objects, attributes, fields, methods, actions, etc. If it doesn’t, it can cause developers a great deal of confusion and frustration. In essence, developers will be forced to learn a new “language” each time they work with one of the SaaS providers solutions. Or, worse still, they’ll end up investing extra effort to re-code everything to resolve the confusion created by the SaaS provider. In short, the API should “speaks for itself” because this is one language barrier that can be a deal breaker. An example of this is CRUD support. The API should support the full set of CRUD (create, read, update, delete) operations for all relevant data objects within the SaaS application. This baseline capability opens up a wide range of integration scenarios. There may be specialized methods on some objects that go beyond basic CRUD (converting a lead in a CRM system, for example, or merging duplicate contact or company records) that the SaaS provider may need to support. These methods should be implemented generically across all objects so that one consistent set of code can be utilized instead of having to program each object on a one-off basis.
- #11Â It goes without saying that safeguarding your customers is of paramount importance. First and foremost, you should think about authentication to your API in the same way you think of access via the application user interface. Implement role-based security, i.e., giving API users the same rights and restrictions as application users. Make sure you have thorough logging of user sessions including who logged in, from what IP address, the actions they took, etc. In this way, you can audit the behavior of your API users and monitor for suspicious or malicious behavior patterns. You also might want to implement delegated authentication methods such as OAuth or Saml versus basic user name and password authentication. This allows your application to be accessed by another without requiring the target application to know the user name and password credentials, dramatically reducing the risk of those credentials being compromised.
- #12 Savvy software providers know that providing great documentation, best practices and tools is part of the complete offering. There are many ways to provide this important support to your ecosystem of developers. For example, the API or the SaaS provider might offer: Free, public and open access to the API. Great error handling is key for designing integrations using an API. When creating integrations, “generic” errors provide little to no value. Providing via the API that the call failed because THIS specific field had THAT specific issue allows someone to read the error, understand the problem and correct that process. Documentation and resources designed by developers especially for developers--resources that are heavy on meaningful and relevant sample code. The SaaS provider should embrace the fact that developers like to figure things out on their own. Access to free developer accounts with minimal restrictions. This allows developers to create, test, demonstrate and support real-life customer scenarios. A very strong support site (and/or forums) where subject matter experts can share their knowledge and experience, where internal and external developers can go to hold discussions and post questions and answers, etc. Certification or validation programs that help others leverage and promote the API’s integration capabilities.
- #13Â Seed Q: 1. 2. 3.