It's client's fault

The quality of the client does not affect the RESTyness of an application. You can have a full boat REST application and stupid clients that choose (for whatever reason) to ignore it and tromp on their way doing whatever they do. Whether it’s a hard coded client shoving requests at the server, or simply a user that simply can not navigate the interface (doesn’t see the links, doesn’t understand them, whatever, wasn’t trained to click the X button, was trained to click the Y button – and the Y button is no longer there).

Motivation to create a more flexible and adaptable client is tied to the difficulty of maintaining that client, the consequences of failure, and the velocity of change on the service that client is using. If someone writes a perl script against an interface that’s been stable for 5 years, for something that can withstand failure IF the service changes, that has no effect on the capabilities and robustness of the service itself.

[…] That’s a client error […], not the applications weakness.
So, write clients as you like. It’s the REST applications promise to provide the proper information for a client to make better decisions, but it can’t force the clients to use that information appropriately, rather all it can do it try and protect itself when they don’t.

Hi there! I recently wrote an ebook on web application security, currently sold on leanpub, the Amazon Kindle store and gumroad.

It contains 160+ pages of content dedicated to securing web applications and improving your security awareness when building web apps, with chapters ranging from explaining how to secure HTTP cookies with the right flags to understanding why it is important to consider joining a bug bounty program.

Feel free to skim through some of the free chapters published on this blog and, if the content seems interesting enough to you, grab a copy on leanpub, the Amazon Kindle store, gumroad or simply checkout right down below!

Buy the Web Application Security ebook for $9.99

In the mood for some more reading?

...or check the archives.