API development is becoming increasingly common for server-side developers thanks to the rise of front-end JavaScript frameworks, iPhone applications, and API-centric architectures. It might seem like grabbing stuff from a data source and shoving it out as JSON would be easy, but surviving changes in business logic, database schema updates, new features, or deprecated endpoints can be a nightmare. After finding many of the existing resources for API development to be lacking, Phil learned a lot of things the hard way through years of trial and error. This book aims to condense that experience, taking examples and explanations further than the trivial apples and pears nonsense tutorials often provide. By passing on some best practices and general good advice you can hit the ground running with API development, combined with some horror stories and how they were overcome/avoided/averted. This book will discuss the theory of designing and building APIs in any language or framework, with this theory applied in PHP-based examples.
About the Author
Phil has seen a few trends come and go during a long and varied career of building stuff for money as an employee, freelancer, consultant and now CTO. One trend over recent years is the rise of APIs as an everyday part of the average server-side developers job. Back in 2009 Phil released a CodeIgniter Rest Server, wrote a few articles about how to use it and built handfuls of APIs for his freelance clients. This tool was fairly basic, but covered HTTP-based routing, HTTP Basic/Digest/API Key authentication, added logging and throttling and did not force CRUD-based conventions. The internet seemed to like it, and this code is still used by Apple, the UN and USA.gov. Later on as a core-contributor to FuelPHP he added this functionality to the core, and again built out a bunch of APIs for people. Then he got a job in NYC, to take over as Lead Engineer for a company that - you guessed it - had a FuelPHP API and wanted to improve it. After two years of working on their API, Phil has moved to Ride.com, building their API with an amazing team of developers. Phil has been building APIs for so long, he has come up with a very long list of ways to make them not suck, and he'd like to share the information with you all.
API development is becoming increasingly common for server-side developers thanks to the rise of front-end JavaScript frameworks, iPhone applications, and API-centric architectures. It might seem like grabbing stuff from a data source and shoving it out as JSON would be easy, but surviving changes in business logic, database schema updates, new features, or deprecated endpoints can be a nightmare. After finding many of the existing resources for API development to be lacking, Phil learned a lot of things the hard way through years of trial and error. This book aims to condense that experience, taking examples and explanations further than the trivial apples and pears nonsense tutorials often provide. By passing on some best practices and general good advice you can hit the ground running with API development, combined with some horror stories and how they were overcome/avoided/averted. This book will discuss the theory of designing and building APIs in any language or framework, with this theory applied in PHP-based examples.
About the Author
Phil has seen a few trends come and go during a long and varied career of building stuff for money as an employee, freelancer, consultant and now CTO. One trend over recent years is the rise of APIs as an everyday part of the average server-side developers job. Back in 2009 Phil released a CodeIgniter Rest Server, wrote a few articles about how to use it and built handfuls of APIs for his freelance clients. This tool was fairly basic, but covered HTTP-based routing, HTTP Basic/Digest/API Key authentication, added logging and throttling and did not force CRUD-based conventions. The internet seemed to like it, and this code is still used by Apple, the UN and USA.gov. Later on as a core-contributor to FuelPHP he added this functionality to the core, and again built out a bunch of APIs for people. Then he got a job in NYC, to take over as Lead Engineer for a company that - you guessed it - had a FuelPHP API and wanted to improve it. After two years of working on their API, Phil has moved to Ride.com, building their API with an amazing team of developers. Phil has been building APIs for so long, he has come up with a very long list of ways to make them not suck, and he'd like to share the information with you all.