More often than not, with simplicity comes greater risk. Making platforms more user-friendly tends to make them more easily compromised by system breaches, by virtue of the fact that there are more elements instituted – precisely to make an interface more readily embraced by a wider network – through which attacks can occur or software/hardware errors can propagate. With regard to the Application Program Interface, for example, this is characterized most prominently by the SOAP-to-REST transition that many API programmers prefer; especially those that are developing broad-spectrum APIs for public consumption or use.
Why is REST Preferred by API Builders?
Simplicity, after all, is the ultimate goal when going for mass consumption. If Adobe or RealAudio were complex systems to navigate, there would be a drop in numbers of people using these APIs regardless of their inherent utility. In fact, they would be quickly displaced as a result of leaving a vacuum into which a new, simpler model can seek purchase. REST is the quintessential software architecture for the Internet client-server relationship because it is as simple as can be (at the moment, at least) while still maintaining the requisite level of sophistication for its many dynamic uses – such as scalability and uniformity in the face of customizability. It’s easy to see why this App-building platform is emerging as the top choice for Software-as-a-Service (SaaS) enterprises.
Rest Security Problems and Solutions
Many of the existing problems with REST security are actually not native to this favorite software architecture platform, but are endemic to all Web-based protocols that employ HTTP. This, of course, doesn’t let REST off the hook. The ease of use enabled by REST’s easy integration into Web-based platforms tends to come with a lax security approach that leaves it up to the programmer to provide his or her own security measures. The latter just isn’t practical, given the highly-competitive and deadline-driven world of App-implementation. Security just naturally falls into the background because it’s easy to leave it up the Web browser, which is supposed to have a level of security – Firewalls, Windows Defender, etc. – already implemented. Needless to say, malware and other unintentional forms of system breach get through web-based Apps somewhat regularly, so these aren’t robust-enough defenses.
Nonetheless, there are definitely ways to secure RESTful applications. Not only can mindful consideration be given to the normal Hypertext Protocol security measures – by making sure integration with REST isn’t relegated to the back-burner – but things such as ensuring authentication of the user by implementing a password requirement, instead of mere single-key authentication. Tokens, WS-Security headers and signed http headers can go a long way in securing the App.
A simple catch-all solution to security issues in general – not merely those associated with REST – is by having an API overseen by a Developer Community, which further confers other benefits. A suite of in-built security measures, from the generation of key-pairs and token exchange, to cryptographic message signatures and whole-system encryption can lend an API, irrespective of the delivery platform of choice, a degree of security indistinguishable from the most robust among them. Essentially, a Developer Community such as SOA Software Community Manager can confer the best of both worlds on an API with REST constitution: user-friendliness with corporate-level security. Given the increasingly-important mobile sphere and the inevitable migration of more APIs to this, there isn’t a better combination of attributes that inspires more confidence.