Securing Ajax Applications

RESTful Web Services

While waiting on the promise of web services, some people jumped ship in favor of a simpler approach. These people feel like the Web already has a model for doing these types of things, and new standards, formats, and protocols are simply not necessary.

These folks are known as the RESTifarians—people who advocate the Representational State Transfer (REST) architectural model over web services (at least for today). No, really, Google them.

They favor REST for implementing a web service-like design. Not that they think web services are bad. They are willing to hang on to some of the good parts, like SOAP and XML in general, but throw out the pieces that are too hard, like UDDI. More likely is the fact that they're an antsy bunch of developers who want something now and don't appreciate the glacial movement of the WS-* standards.

Why Use REST?

The basic idea is why do we have to reinvent the wheel? Can't we just make some of this stuff work without having to create a brand-new framework and protocol?

As for me I see value in both approaches, but feel that it is really tempting to cut corners when you implement REST. And when you start cutting corners it almost always impacts security.

That said, I think you should consider using REST if:

• You want an easy learning curve for developers.

• You have limited bandwidth or high user load.

• Web caching or proxies would measurably improve performance.

• Clients already know how to use your services.

• Your services are stateless.

Who Is ...