Downloaded 14 times
Uploaded byMarsh Gardiner
APIs for App Developers
The document discusses best practices for app developers using APIs. It recommends starting by understanding the presentation tier requirements and finding APIs to meet them. It warns that issues like authentication, authorization and cross-origin resource sharing will be encountered. It suggests using a proxy to work around blockers and move technical logic from the presentation tier to prevent bloat. The proxy should also be monitored for bloat, moving business logic behind APIs when needed. Non-functional requirements should be consolidated at the proxy rather than individual APIs.
APIs for App Developers
- 1. APIs for AppDevelopers Marsh Gardiner Apigee @apigee @earth2marsh
- 2. 5 years fromnow…
- 5. … and evenBaaS • StackMob • Parse • Usergrid
- 6. 5 years fromnow…
- 8. Four quick tipsto help you survive.
- 15. Four survival tipsrecap • Understand the business model • Consider their lifecycle • Don’t ignore the Terms of Service • Never forget you’re sharecropping
- 16. There will beissues… • Authentication • Authorization • APIs not under your control • Cross Origin Resource Sharing • Logic Bloat in Presentation Tier
- 17. Presentation image image image
- 18.
- 19.
- 20. A 3-Tier WebArchitecture image image image Presentation HTTP Mobile Web Logic Binary Web Data
- 21. The New 3-TierArchitecture image image Presentation image Mobile Web Web HTTP PROXY Tech Logic HTTP APIs Biz Logic Data
- 22. Start with thepresentation tier.
- 23. Look for APIsto meet app requirements.
- 24. You will runinto issues and blockers eventually.
- 25. Work around blockerswith the proxy.
- 26. Watch for bloatin the presentation tier. Move technical bloat to proxy.
- 27. Watch for bloatin the proxy. Move business logic bloat behind an API.
- 28. Move non-functional requirementsfrom individual APIs to proxy.
- 30.
- 31. THANK YOU Contact meat: @earth2marsh marsh@apigee.com
Editor's Notes
- #2 Hi, I’m Marsh. I work at Apigee.Apigee exists in order to help machines talk to each other…… and to help people help the machines.
- #3 Pause for a moment and think about what’s coming in five years.First, a quick reminder about where we are right now…Computers that fit in your pocketComputers that know where they are.Computers that are vastly simpler to use than ever before.
- #4 Revolutions don't happen all that often, and we're deep in the middle of one that started roughly five years ago. On the client side, the iPhone is the poster child. There was no stylus, no mouse. You touched it. It made computing fun again.
- #5 And at the same time, almost as much innovation has been happening on the server side as the client side.IaaS has been driving down the cost of operating datacentersPaaS has been reducing the maintenance burden of the backend stackSaaS—on top of virtualized hardware and operating systems, applications moved into the cloud.And all the clients that proliferated talked to those services using APIs.
- #6 We’re starting to see specialization of those layers, such as Backend-as-a-Service.These exist because time and again the same patterns appear in apps, such as users, activity streams, relationships, schema-less datastores, etc.
- #7 Now back to that question from earlier.Think for a moment how much has happened in the last five years, and then think about what we know is coming in the next 5 years… … and that amount of change can be scary. Because here’s one thing that was predicted that will happen in 2018. And here’s a hint—it involves machines that are talking to each other…
- #8 … because five years from now, in 2018 we will see SkyNet rise up. And how will the machines communicate? That’s right. APIs. SkyNet IS APIs.So you need to be thoughtful about APIs—you can’t expect some Schwarzenegger-type to travel through time to save you.
- #9 In the spirit of survival, here are four tips. (story about father-in-law’s foot and what foot-health says about general health)
- #10 Do they have a reasonable business model? Do you understand how they make money, at least in theory? What would happen if they were acquired?(simplegeo example. I don’t know if they were acquired for talent, technology, or what, but what I do know is that they shut down all their endpoints and apps that were using them had to change their code or they stopped working.)Before using an API, look at the company or organization putting it out. Do YOU understand THEIR business model? Judge a service's general health by whether their business model makes sense to you.
- #11 Where are they in their lifecycle? Over the last year, we’ve watched Twitter exert more control over their ecosystem. In the beginning, there were no 1st party Twitter clients. And over time, as mobile became more important, they sent a message that they considered that part of the core Twitter experience. And that wasn’t always good for the folks who had sunk a lot of work into making full-featured Twitter clients.
- #12 Read the Terms of Service—don’t ignore them. Would you use code in your app that wasn't licensed? It is just as irresponsible to not understand how a service's ToS impact your app.Aviary’s are the easiest to read. If they spent that much time considering the needs of their developers on just the ToS, imagine how thoughtful they are about the API itself!
- #13 4. Remember, you are sharecropping. This is the price of being able to build amazing apps without having to build all of that technical complexity yourself. But it means that there are things that are beyond your control. The ground you’re working doesn’t belong to you. And that’s not a bad thing, necessarily, it just means you need to be thoughtful about how you build.(ask who lives in SF, then who rents. Those with hands up have chosen to make a home in a building that isn’t theirs. Remember when you use an API, it's like building a home in a house that you don't own.)(Farm Security Administration sharecropper photo of Mrs. Handley and some of her children in Walker County, Alabama.)
- #14 … because this is what happens when you build something without expecting the ground to move. Thinking about how to be flexible when the ground shifts is important to making great apps
- #15 … and it is why AT&T Park, where the Giant’s play, has these rubber sections in their pipes so that the sections of the stadium can move somewhat. You can do the same thing with how you build apps, so that when things happen beyond your control, everything doesn’t break.
- #16 Those tips may help guide you…
- #17 … but there will be plenty of other issues you’ll face. Let’s talk about the ways things used to be built, and the ways in which we’ve seen application development shifting to what we’re calling, “The NEW 3-tier architecture.
- #18 As a web pattern, we used to see this a lot. The browser was the presentation layer, and it used HTML, JavaScript, and CSS that would be rendered in the browser.
- #19 There was logic that ran server-side…
- #20 And servers were hooked into databases.
- #21 If you put it together, it looks like this.And this 3-tier web architecture did a pretty decent job of powering the web and the mobile web.But when you move to mobile apps, and when you start leveraging APIs , you get…
- #22 The NEW 3-Tier Architecture. Now we see a presentation layer similar to before, but the data is all passing via APIs. The proxy handles the technical logic, and the backend handles business logic.
- #29 Transformations, pagination, authentication…
- #30 And enjoy life in rainbow-land.
- #31 We write and blog about these kinds of topics all the time. You can find a much longer versions of the 3-tier architecture and lots more about apps and APIs.
- #32 Special thanks to @landlessness and @kevinswiber for some slides, ideas, and general awesomeness.