Posts tagged REST
Top 10 Security Issues for REST APIs – Webinar with Gunnar Peterson on September 18

REST API security has come a long way from being a case of “Just use SSL.”

Or has it?

On September 18th at 11 a.m. EDT  (4 p.m. GMT+1), we’re running a webinar with Gunnar Peterson on the Top 10 Security Issues for REST APIs.

One of the big criticisms of SOAP Web Services was the complexity of the security standards such as WS-Security, WS-Trust, WS-Policy, WS-PolicyAttachment — the list goes on. People wrote whole books about them ;-) . In the case of REST, it can worryingly seem like a case of the Wild West (the “Wild REST”).

Now, there are standards such as OAuth, but also there are many conventions such as API keys which are sometimes implemented insecurely. Even in the case of OAuth 2.0, the implementation itself must be secured. Look out for this, and more, in Gunnar’s definitive Top 10.

And because the topic of REST API security is so hot, we’re running the webinar twice. If you’re in the Asia-Pacific region, you can attend Gunnar’s REST API security webinar on Tuesday, September 23rd at 10 a.m. Hong Kong / 12 p.m. Sydney/Melbourne time.

(Originally posted in slightly different form at


Times Up! — Deciding What to Do As Standard Maintenance Ends with DataPower

We’re now at the end of standard maintenance on several DataPower SOA appliances. And that probably means most companies who haven’t yet upgraded are buying extended support, because you don’t just replace appliances for important applications — you test and deploy over many months so that you don’t put the business at risk. If you’re in this situation, use the next 1-2 years wisely to rightsize DataPower, and break the vicious spending cycle.

When it comes to appliances, many companies buy excess capacity up front to support several years of growth. Often it’s because they don’t want to be forced to do an early upgrade or add-on purchase. Most are convinced they will use the extra capacity for other projects. And this is the vicious cycle. Companies end up putting applications on DataPower that just don’t belong there. DataPower is great as an XSLT acceleration engine, but that’s mostly it, and that “data power” comes at a big cost. Don’t keep loading up DataPower. Start to evaluate which applications don’t belong there, and start to implement your rightsizing program now. Then, buy the right size of DataPower for what’s left.

Reevaluate all new projects and see what can be moved to another platform before you put it on DataPower. Any integration across a firewall or across divisions can probably be done using an API gateway. The right API gateway will have native wire-speed integration with DataPower that makes it easy to add it to a DataPower deployment, migrate workloads, or add functionality to other deployments.

Finally, build out your roadmap for migrating existing functionality that can or should be run on other platforms, either during release cycles for the applications or as part of a larger initiative. Some of the more common reasons for moving to an API gateway are:

  • A move to virtualization or an outsourcing strategy. DataPower isn’t designed to run on a third-party virtualized infrastructure such as VMware or Amazon AWS.
  • A need to support cloud and mobility. DataPower supports XML. It’s not good at supporting the new world of JSON and REST.
  • Productivity. DataPower requires developers to code in XSLT. A modern API gateway is a highly graphical environment, where developers configure, not code.
  • Native support for Java or JavaScript. DataPower doesn’t support either.
  • Antivirus protection and security concerns. DataPower requires an ICAP connection to add anti-virus protection, which adds an extra network “hop” and a delayed response. The right API gateway supports antivirus in-process and a host of security measures for hardening access from outside the firewall.
  • Identity bridging. DataPower does not directly support bridging OAuth, Oracle Identity Management, CA SiteMinder, or even Tivoli as well as a quality API gateway that delivers federated identity management and single sign-on (SSO) across the old and new channels.

So build your roadmap now. Start by identifying the strengths and weaknesses of DataPower and evaluate each application it supports. Get advice from others who have used API gateways with DataPower. Use some of the money that had once been earmarked for extended support — and extra capacity — to work on new projects that make a difference to the business.