API Services: Building State-of-the-Art APIs

Editor's Notes

• #2: This session is about techniques that can be used to optimize API development and delivery on the Apigee platformCome away with a sense of how these techniques can be used in your environmentThis is part 1 of a two-part session. Part 2 is immediately after this session, in the same room, hosted by my colleague Alan Ho.Take some time to try these things out, and then send us your feedback
• #3: We’ll get this going with something super-simple: securitySecurity forms the bedrock of any API implementation, and in the first part of this session we’re going to spend some time both talking about security in the abstract and also demonstrating how you can implement security in your API proxies. I also want to share some thoughts on something that you may not think about when implementing proxies – methods for configuring proxy behavior that are often very important but don’t necessarily get the level of thought that other areas do. We’ll also spend a bit of quality time introducing you to some of the new scripting options that can dramatically increase the flexibility you have when determining how to design and build API proxies with Apigee, even beyond what you had with configurable proxies alone, and we’ll finish with a discussion of the API Services Data Store and how you can use it to meld the requirements of external apps – mobile or not – with the data and processes from the enterprise.So, let’s get to it.
• #4: B2B – generally heavily vetted relationship. Most of the time the data is not specific to a particular user. Independent of the user authentication process. Could run autonomously.Mobile apps from trusted developers – push the user experience by doing things other apps can’t, like have access to user credentials and details. Mobile apps from untrusted developers – cannot be trusted to handle user credentials and sensitive data well. HTML5 – inherently insecure because everything is out in the open.
• #5: OAuth is the most widely accepted way of authenticating and authorizing users and data.OAuth defines a concept of a “grant type”, which represents the resource owner’s authorization to use a specific type of resource. Grant flows generate an access token which is used to represent that authorization for API requests.OAuth also defines a concept called “scope” which is a named set of API resources that can be accessed. Applications can request a specific scope, or they can be given a default scope.B2B – validate using application identifier (API key and shared secret)Trusted developer app – validate using a combination of application identifier (verify that it’s a trusted app) and user credentials.Untrusted developer app – no access to credentials. Requires some sort of server to validate user credentials and obtain user’s consent for app to access data. Customers can provide this authentication server, or Apigee can act in that role.HTM5 – because app is inherently insecure, implicit grant doesn’t generally require app credentials at all, just user credentials.Apigee supports all of these OAuth grant types through built-in policies for both OAuth v1.0a and OAuth v2.0. OAuth 1.0 policy is an older version that uses signatures to authenticate a request, and OAuth 2.0 is the more recent version. Single policy, configurable to perform each of the different grant types. Highly configurable, so data to perform the grant can be taken from headers, path variables, query params or payload.
• #6: While not strictly an authentication mechanism, identity tracking using API keys allows you to track who’s using your API and to enforce certain restrictions, such as rate limits.Identity tracking is most appropriate when there’s no user data involved and there are no other restrictions on the data. Suitable for apps such as HTML5 widgets which developers would like to get widely adopted.
• #7: Tou also need to be concerned about threat protection. Spike arrest – common concept - protects you against instantaneous bursts in traffic. Here’s something to give you a sense of why this is needed even in non-attack scenarios: One of our customers once had an application that checked the weather at the top and bottom of the hour, which doesn’t sound all that bad until you consider that there were hundreds of thousands of copies of this app in the field…so that simple weather check turned into a twice-hourly denial-of-service attack. The attack caused their back-end systems a pretty large amount of trouble until they implemented spike arrest to allow them to manage these huge influxes of inadvertent traffic.Injection and scripting attacks – common concept - can cause security breaches and all sorts of other mayhem. I think we’ve probably all heard the story of the school student whose name was “DROP TABLE STUDENTS” and how that caused a school to delete its student database, but it’s also possible for APIs to post scripts that makes their way into Web forms and open up the possibility of compromised user security.XML and JSON attacks may not be quite as obvious, but they can be just as damaging. XML and JSON documents can be nested to ten thousand levels, or contain element, attribute or object names that are megabytes in length, and so on. Apigee provides a spike arrest policy that allows for per-minute and per-second traffic burst handling.The configurable XML and JSON attack policies to tell Apigee what’s allowable and what’s not, so that a payload that doesn’t match your parameters can be rejected.Regular expression protection allows you to inspect any part of an inbound request for the marks of a number of different types of attacks, such as SQL or Javascript injection attacksIn some cases it’s appropriate to restrict specific APIs to only certain IP addresses at the API level – when certain requests are internal-only, for example. And of course, you can use Apigee’s scripting capabilities – which we’ll talk about later – to restrict APIs based on just about any other criteria you can name.
• #9: We’ve talked about the general considerations around security, and you’ve seen a bit of how Apigee Edge’s built-in functionality enables you a lot of flexibility in setting up OAuth, adding threat protection and so on. Let’s talk now about something that we see quite a bit – the need to tailor proxy runtime operations without deploying a new version of the proxy.
• #10: External configuration of proxies is one of those things that proxy developers tend not to think much about, but it’s a hugely useful feature for anything from tweaking cache expiration across multiple proxies to fixing scripting bugs. HTTP Basic Authorization credentials are a great example of something that should NOT be configured in a proxy.There are currently four ways to externally configure proxies… A couple of these you may already know about since they’re readily accessible via the API:-- Using API Products, which controls who has access to what, via what key;-- Using custom attributes on the various entities in the system, which allows you to set developer- or application-specific params and even make this functionality available to business users if desiredKey-value maps can be used as a persistent storage facility for configuration information or runtime data (including things like base64-encoded userids and passwords).Organization- and environment-level resources such as scripts, allow you to make larger-scale changes in processing and can be really useful in situations where a specific type of functionality is used across many different proxies.Using organization- and environment-level resources also has other obvious benefits like reducing policy asset redundancy across bundles, so we’ll dig into that in more detail in our next demo.
• #12: Okay, you’ve got your proxies secured and configured, so let’s talk about scripting and one of the new enhancements in Apigee Edge that we’re pretty excited about – node.js support.
• #13: If you’ve been working with Apigee for a while you’re probably already familiar with the scripting that Apigee provided early on:-- Java, which is super-powerful and super-fast but also a bit clunky to use because of the need to bundle class files into JARs before deployment-- Python, which is quite powerful and allows you to do just about anything you’d want to do in a language that many find easier to deal with-- XSLT, which was great for transforming XML files but admitted not much good for anything elseWhen 4G came out in August of 2012 we added JavaScript support, which opened things up quite a bit because of the relatively large number of developers that know JavaScript already. Node.js support in Apigee Edge introduces the concept of what we call a “scriptable target”. With node.js, you now have the ability to think of Apigee Edge as a target in and of itself, which can potentially enable some really interesting use cases and capabilities.
• #14: Node.js and the idea of scriptable targets support enables a new level of API customization. One great use case for scriptable targets is what’s called an “OAuth consent application”. You may already know that in three-legged OAuth there’s a concept of an “authentication server” that is used to verify user credentials and to ask for and record the user permission to share their information with an application. Many of our customers ask us to host this application within Apigee because they don’t have an outboard server that has this capability; with node.js you now have the ability to host this sort of application within Apigee, which simplifies your API authorization and authentication flows considerably.In general, node.js support can help eliminate the need for separate node.js servers – you can now host those apps in the scalable Apigee cloud.Node.js gives you the ability to orchestrate calls, perform complex transformations, and do almost anything a regular node.js app can do, but now you can combine that with Apigee policies for even more flexibility.The really great thing is that you can also use many of the thousands of existing Node.js modules.
• #15: Getting started with node.js is pretty easy.. We’ve provided a wizard that allows you use your node.js code to create a proxy using the “New API Proxy” wizard, and you can also add API key validation and quota enforcement at the same time. When you fill out the form and click Build, API Services builds the proxy, deploys it to the “test” environment and sends you to the Proxy Overview page where you can go to Develop mode to add any policies or other customizations.The Wizard allows you to select from two templates that you can use to start your development – the basic “hello world” template and one that incorporates the API Services data store to allow you to access that data as a scriptable target. There’s another way to create a node.js application – using “apigeetool”
• #16: Apigeetool is a utility you can download from Github and install to allow you to create Apigee proxies from any node.js server module.Apigeetool allows you to do just about everything the API Proxy Wizard can do – name your proxy, set the base path and so on.It’s pretty easy to use.
• #17: Apigee’snode.js support comes with a set of built-in NPMs that you can use in your scriptable targets. Like other Apigee resources, node.js scripts can also be stored at the organization and environment level, so they’re easy to change.
• #19: Last but certainly not least we’re going to spend a few minutes talking about the API Services Data Store and how it can be used not only as pre-built data storage for mobile apps but also as a mechanism for managing the impedance mismatch between mobile data and access requirements and typical enterprise data storage.
• #20: The API Services Data Store provides the ability to create an “operational data store” that can serve as an intermediary between mobile and enterprise.Looking at the data store from the mobile side, it’s pre-configured with many of the common concepts you’d want in a database to support mobile apps, such as location, connections and social integrations. It’s also extensible: new collections of data can be created and used very easily, using the Apigee Edge UI or the Data Store API. The Data Store supports user authentication as API Proxies do, and as part of its social integration it also supports login using credentials from providers like Facebook.A key concept of the data store is the ability to create connections between pieces of data, so that you can – for example - associate an item representing an activity with the place it was performed and the person that performed itHandling of location data – latitude and longitude – is also a key concept, and there are specific features of the query language that allow you to retrieve data based on the location of the object that data represents.Push notifications allow you to drive user engagement, and you can use features such as the Data Store and node.js to generate push notifications when new data is inserted into the data store.
• #21: From the enterprise perspective, the Data Store provides an ability to take in data from disparate systems and make it available to mobile apps in a way that’s natural and easy for them to use. There are any number of reasons why this could be important – you don’t want every app hitting your SAP system, or the data in your legacy app is not structured for optimal use by the types of apps you want to build, or you just want to push the data closer to your mobile users for performance reasons. Combining this with the ability to link this data to data generated by the mobile apps themselves, and you have a powerful tool for building awesome user experiences.Let’s go take a look at the Data Store in action.