When building a new API there are numerous decisions you’ll have to make along the way, but you could argue that none are more critical than the type of API you want to create. You have to take into consideration what kind of clients will consume the API, their technology stack, how they will connect to the API, and what the API will be used for. In the .NET world, this typically leads you to three choices: ASMX, WCF, and REST.
With ASMX and WCF, you’re basically forcing clients of your API to be .NET specific. That no doubt works for many people, and with us being a .NET ecommerce platform we certainly could have taken the same approach. However, we didn’t want to handcuff anybody to a single technology. Just because we chose to implement our API using .NET shouldn’t mean that consumers of the API must be .NET as well. Seems kind of silly and limiting.
The single biggest reason we chose REST for our API is because it’s technology-agnostic.
REST is built on the fundamentals of HTTP, so any web technology can use it. Ruby, PHP, .NET, Java, Python, whatever. It doesn’t really matter, and that was extremely important for us as we move forward as an ecommerce platform. We want as many people consuming our API as possible, and implementing the API in REST allows this to happen.