There's a balance in there between "getting it done" and "getting it right(tm)" and then there's the definition of "right" ;) "Getting it done" is great for so

There's a balance in there between "getting it done" and "getting it right(tm)" and then there's the definition of "right" ;) "Getting it done" is great for something entirely internal where you have control over all the end points. You have insight and understanding that you don't have to express to anyone outside your organization. Further, if you get it "wrong" deploying updates and new versions is easy (by comparison). "Getting it right" is key if you want something to go beyond your immediate circles. It should be as self-descriptive as possible to promote clarity. It should be consistent as possible to improve documentation/understanding. And the risk if you get it "wrong" is much higher because there are end points/API consumers that are not under your control, therefore you have to support a variety of versions for potentially long periods of time. (Biased as I regularly speak on API design and work for Twilio. We have a 2008 and 2010 version of the API. While we still fully support the 2008 version, the 2010 version has a great deal more functionality.)