4 ms·

The article starts with this...."Designing a REST API is not easy. No, really! If you want to design an API the right way, you have to think a lot about everyth

The article starts with this...."Designing a REST API is not easy. No, really! If you want to design an API the right way, you have to think a lot about everything, and either to be pragmatic or to be an API terrorist. It’s not just about GET, POST, PUT, and DELETE. In real life, you have relations between resources, the need to move a resource somewhere else (think about a tree), or you may want to set a specific value to a resource." It seems like developers are making this too hard. At some point you're just sending data over http, so why does this have to be dogmatic and needlessly complicated just to match some mystical HATEOS spec that doesn't need to exist to get the job done?

caseysoftware 14y ago
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.)

4 ms·

The article starts with this...."Designing a REST API is not easy. No, really! If you want to design an API the right way, you have to think a lot about everyth

by programminggeek 14y ago

caseysoftware 14y ago
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.)