It's often a good thought experiment to read something with a "developer" hat on, and then read the same thing with a "security" hat on. There is a classic example of this in a comment today on the Service Oriented blog:
REST is so simple to implement, that its like a doggie door... something that will let anything in, when you want to provide open interfaces. When you don't know what you're going to be hooking up, REST is good!A REST API is indeed a great way to allow a multitude of devices and apps to consume a service. Almost any app can create a simple HTTP GET and pass some parameters with it because, as people say, "it's just a wget".
But wait, what about security? In the doggy door analogy, what if a snake or, if you're in Florida, a lizard comes in through that doggy door? In the REST world, the snakes and lizards are malicious users, who want to use REST services for data-mining or denial of service. For this reason it is important that REST APIs are protected and managed. However, back to the doggy door analogy, it is just as important to not make that doggy door so complex that the dog gives up and goes elsewhere. In that case, you'd be locking the dog out with the snakes and lizards.
For all these reasons, REST API management has to enable the right apps and devices to connect, without placing onerous requirements on them. Remember that REST exists to be easy to use, so if you force clients to suddenly place honking great security assertions into each request, they will be turned off.
So what is the solution? I've written about the options for securing REST API's before, and I recommend checking out this 40-minute video explaining how REST APIs can be deployed safely. The key is to choose an authentication scheme which can be supported by the widest variety of clients, leveraging open standards and best practices. Wind the video on to minute 20 to see how the "REST doggy door" can be secured.