I’ve been getting good feedback on my Web API course on Pluralsight but some of the comments have concerned me. Lots of the students (from my small sample size) seem to be trying to infer how to *design* an API, not just implement one. That course is specifically about how to implement an API.

What’s important as far as I am concerned is to well design the API (regardless of which way you implement the API). So if you’re starting to use Web API and you need an API for your app, for your customers, or for others to consume (e.g. 3rd party developers) – stop figuring out how to implement the API and go back and design the API.

This is especially important if you are new to the notions of REST. Essentially, you need to understand the ‘Why’ instead of focusing so much on ‘How’.

I have been writing software a long time and I have found that when you start a new project or work with a new technology, you tend to try and apply your old ideas to the new toy. That is why sometimes we are so aggravated with a technology right before the pieces fall into place and we understand *why* it wants us to do something. When I first looked at creating APIs over HTTP, I was in the Silverlight mindset. At that point the notion of REST puzzled me because I didn’t understand why resource based architectures were so important. I didn’t understand that versioning was more than just putting a number in the URL. I didn’t understand that self-describing data payloads would help my developer audience. That’s a crucial step to getting an API designed. Implementing ends up being much easier once you know what you’re building is meeting the needs of your clients today and tomorrow.

I do have a course on API design at Pluralsight, but even if you don’t watch that course, I implore you to spend time understanding why REST, HATEOAS, Resource-based architectures, versioning, and security are so important to an API. It’s worth the time. I promise.