Buy A Bundle And Save
About the Book
If you read the tech press, everyone knows they need an API but most aren't really sure what it is. They treat it as another checkbox like "Web 2.0" was a few years ago or a mobile app was most recently. In fact, there’s an entire “API-first” movement in development circles that most people don’t understand or even realize why. In this book, we'll start by discussing the what an API is, why you might need one, and follow up with the how to build one.
This book is incomplete. In accordance with the Lean Methodology, we wanted to get a Minimum Viable Product out there into people’s hands as quickly as possible to gauge interest, collect feedback, and make sure that the work we’re doing means something to someone. As a result, we hope this book becomes a conversation as we continue writing. When you find something interesting, let us know. If you think we’re wrong, say so. If you think we’re right, tell your friends. If you want us to teach your team more and deeper concepts, please let us know.
Towards that goal, here are the chapters currently on our drawing board:
-
API Design Patterns
- Idempotency
- SOLID Design Principles
- Naming - Resources & Parameters
- Transactions
- Authorization - Tokens vs Credentials
- Link Relations
- Composites
- Versioning
- Pagination
- Error Handling
- Caching - Strategies & ETags
- Hard vs Soft Deletes
-
Data Architecture
- Hypermedia Specifications
- Data stores and storage
-
API Product Management
- Team Dynamics
- Partitioning API Teams
- Selecting your Infrastructure
- Estimating Costs
- Release Management
- Automation
-
Community & Support
- Documentation
- SDKs
- Third-party development portals
- Evangelism
-
Installments completed
- 2 / 3
-
Feedback
Share this book
Table of Contents
- Welcome
- Changelog
-
Chapter 1 - APIs: An Introduction
- What is an API
- Why you should have an API
-
Chapter 2 - Principles of Pragmatic API Design
- API or SOA?
- API and SOA: Extend and Accelerate
- REST vs. SOAP
- APIs for Existing Applications
-
Chapter 3 - Beyond CRUD
- Building APIs for Business Workflows
- Affordances
- Why you should trust others’ APIs
-
Chapter 4 - The API Modeling Process
- Summary of the Steps
- Step 1: Identify the Participants
- Step 2: Identify the Activities
- Step 3: Break Each Activity Into Steps
- Step 4: Create and Group API Methods
- Step 5: Validate the API By Testing
- Common Questions About API Modeling
- Next Step: Design
-
Chapter 5 - The Principles of HTTP and REST
- HTTP Core Concepts
- Web APIs and the Richardson Maturity Model
- Back to Basics: The 6 REST Constraints
- The Next Steps
-
Chapter 6 - From Modeling to RESTful Design
- Building Your Resource Taxonomy
- Defining Resource Lifecycles
- Mapping Response Codes For Success and Failure
- Expanding Resources Through Hypermedia Linking
- Common Questions About API Design
- Next steps
-
Closing.. for now
- Want to stay informed about everything API-related?
About the Authors
Keith Casey is a problem solver with over a decade of experience in software development in general and project management specifically. He has seen projects and teams that run like clockwork accomplishing amazing things and others that make the Titanic look like a pleasure cruise. He discovered pretty quickly that the only way to avoid the iceberg is to get the right information to the right people as quickly as possible.
Keith started his career at the Library of Congress in Washington, DC where he was working to answer the ultimate geek question "how much data is in the Library of Congress?" During that work, he drafted two of the XML standards still in use by the Library for Audio and Video metadata collection. On the technical side, he developed FoxNews' mobile sites (pre-iPhone) from concept to launch in 45 days; the voting system for live musical performance show; the news syndication system for Cygnus Business Media (65 sites across 8 verticals); and the Drupal-based syndication system for a professional sports league and its teams.
In 2011, he joined Twilio as a Developer Evangelist bringing communications APIs to the world. In those two years, he led most outreach efforts within the central US and the larger PHP community. Further, he's led many customer-focused efforts to help them use the API in new and creative ways to drive their own revenue and customer experiences. He is currently an working with a number of companies on API design principles, software quality assurance, and software project triage and recovery.
James Higginbotham has over 15 years of experience and has architected, built, and deployed software products for both Fortune 500 companies and early-stage startups. He combines his love of software with a focus on the product experience to create a balance between the complexity of scalability and ease of use.
His experience with both startups and the Fortune 500 provides deep insight into accelerating product development at any scale. James has delivered a wide variety of solutions for the healthcare, commercial insurance, non-profit, and airline industries. His solutions include software-as-a-service, supply chain management, and building multi-sided marketplace solutions.
James has deployed to the public cloud and internal data centers. His goal is to design and build software that balances the complexity of scalability and distributed computing with the ease of a modular, testable codebase. He believes that APIs should be designed to solve problems based on the workflows of the industry while providing a great developer experience.
He is the founder of an Austin-based services company that focuses on API design, development, and cloud infrastructure.