Preventing DoS attacks with puzzles

So when a web service is getting too much traffic it starts returning the 503 status code. Well written services also return the Retry-After header hinting the client when it should come back again. Good behaving clients then respect that or will back-off by themselves to make sure the server is not getting too much traffic. However this is not enough if there are bad behaving clients in the mix. And how do you identify the bad behaving clients?

Do I need a new version of my REST API when I add something?

So today I will not talk about how to version REST APIs but rather how you can deal with certain changes. Specifically I want to talk about adding properties to an entity and then adding supported values to a list of predefined values for a property.

Configuration files or APIs

Configuration files is something we have always been familiar with and with cloud services I think more and more configuration has started to move into code. But I was very intrigued by yet a different concept used by a team I worked with a while back; configuration APIs for temporary changes.

REST efficiency

Making simple REST API is easy but once you do more complex things you don't want to stick with the simple rules any more.

Protecting your resource identifiers

In a lot of older web applications as well as newer RESTful services I've seen it fairly common to have identifiers such as user and order IDs just being an auto incremented primary key from the database. This approach has the problem of revealing your total number of users/orders in a certain time period. Information your competitors could use against you!