They are also best avoided. Design for failure.
216 karma · joined February 9, 2016
They are also best avoided. Design for failure.
For example, in the Idempotency section, the author states that for GET requests "no change in application state should occur" which is good, but then also states "the response should always be the same" which is incorrect. There's nothing that says the response cant change, if the resource has changed, but the constraint is that it cant cant _as a result_ of the GET request. This is an important distinction.
DELETEing a resource twice, the second delete should be a NOOP, not a 404.
There's some excellent NDC Oslo & London talks covering more in-depth RESTful topics that I'd recommend checking out if the content of the article is an eye opener for you.
Oh and please please please, put some effort into multi-account detection (if not a side project). It's really annoying / unprofessional to trigger off a new series of On-boarding emails just because I added a new org.
Also, price appropriately, just because your unlimited plan is stupidly priced wont make people thing the solo plan is reasonable if it's not. Ask your early customers what they're using and what features they'd use/pay for if individually offered to them.