A-Z REST APIs using CakePHP - Anthony Putignano @a_putignano

A-Z REST APIs using CakePHP - Anthony Putignano @a_putignano
A-Z REST APIs using CakePHP - Anthony Putignano @a_putignano
Title : A-Z REST APIs using CakePHP - Anthony Putignano @a_putignano
Duration : 33:09
Channel : CakePHP
Label : CakePHP (Software), CakeFest 2013, REST APIs, REST
A-Z REST APIs using CakePHP - Anthony Putignano @a_putignano
A-Z REST APIs using CakePHP - Anthony Putignano @a_putignano
A-Z REST APIs using CakePHP - Anthony Putignano @a_putignano
A-Z REST APIs using CakePHP - Anthony Putignano @a_putignano

I lead the development team at a Philly-based startup called WizeHive. Ever collect a lot of data in Google Spreadsheets, Wufoo, etc? Ever use Basecamp, Trello, etc? WizeHive fuses these two concepts, allowing you to collect massive amounts of structured data from both inside & outside an organization, and manage internal projects around that structured data. WizeHive is a really popular solution for scholarship & grant application processes, contests, etc. Recently, we decided to re-imagine the technology behind the platform and build a REST API. We've been in production with Cake for a long time, but this next version will be released to production in July. Needless to say, we learned a lot. We wrote a ton of reusable code. And we finally decided - it's time we contribute back to the CakePHP community. Over the summer, we will be open-sourcing some really cool plugins. And we were hoping that I'd get the chance to demonstrate those plugins and the lessons behind the API in general at this year's CakeFest. Here's a taste of what I'll talk about: * Input/Output Data Purification: ... is one of the first problem patterns you start to see evolve as you develop out a REST API. When you receive URL queries, you need to turn them into model conditions. When you receive input data, you need to convert it from the API format into something multiple models can understand and save. Rather than solve this problem in each individual controller, we created a couple highly abstract components - the `QueryComponent` and `InputDataComponent`. Using knowledge about how the API maps user-facing attributes to backend-centric model/table data, these components seamlessly convert most of our data. * Permissions: ... become a huge issue. Relying too heavily on the ACL puts you in performance hell. But that doesn't make the ACL useless. It's a great backbone and we decided to use it as such. Using our setup, it is possible to get very fine-grained permission rules working in no time. Our entire app is now enforcing extremely complex permissions using one ACL-inspired component, and a handful of authorization methods per model. * An Authentication & Authorization Protocol/Framework: For a variety of reasons, we settled on oAuth 2. And one of the first things we discovered was that, because oAuth 2 was relatively new, there weren't a ton of great CakePHP options for it out there. There was one popular plugin, but there were a slew of issues with it, not the least of which was a lack of any unit tests. So we rolled our own plugin. One of the neater things we accomplished with it was the creation of an `OAuth2Authenticate` adapter, which seamlessly handles oAuth2 authentication in a very Cake-friendly (read: non-hacky) way. * Cross-Origin Resource Sharing (CORS): Many clients will inevitably connect to your REST API from another domain. CORS support is a must for every modern web application, but CakePHP does not deal with this out of the box. We created a dispatch filter which allows for efficient CORS OPTIONS handling. * Documentation: We decided to use Swagger UI - https://developers.helloreverb.com/swagger/ - for documentation, and the biggest problem we wanted to solve was automating it. We now have a shell utility which, upon deployment, scans a variety of code - API attributes, validation rules, routes, etc - and parses the data into a highly readable & interactive documentation system. As you can see, there are lots of valuable lessons here, and it won't hurt that we'll be open sourcing the result of some of them for others to explore immediately after the talk.



Share this

Related Posts

Previous
Next Post »