The basic APIs are in place! But they aren't really ready for the real world. Ensure that your APIs are robust, error-free and easy to use and understand for all the consumers
Hey there! Welcome to our new series! This series is a a short sequel to our previous two series Microservices-I: Pre-Development and Microservices-II:Basic Microservice Development. If you still haven't had a chance to scan through these series, go ahead and give them a read!
Now, why exactly are we insisting on this? You see...here's the thing....
We started off a chain of blog series on Microservices development and we wanted to illustrate the concepts using a pet project. Quite literally! Our project is a "petstore application" !
We started from ground zero with planning and designing in the first series, Microservices-I: Pre-Development, and continued on to develop the basic APIs in the next series, Microservices-II:Basic Microservice Development .
And since both of these are using the same project as an example, this series too will continue with the petstore application. That's why we're saying, if you just skim through the previous series, you'll have a better context of what we're talking about in the upcoming posts ('Cuz we don't want you to be completely lost while reading our posts!)
So Whats this Series about ?
You already have an application with a working set of APIs. What now? Chill of course! After all, the development is done! Right?
Ha! Not quite! You might think so, but there are so many little things that are still pending and before they are complete, you can't really say it's done.
Remember why you create APIs. You create them so that someone ELSE can use your application. So most of the times, the person consuming your API will have no idea how your application works internally. That means there a number of things you'll have to ensure when you are handing over your developed APIs to someone else to use.
You'll have to ensure that your code is robust and error free.Your code works for the ideal situation where proper input entails a correct output. Great! But who knows what all different inputs the users may provide (they don't know the internal workings of your system remember!). That means you'll have to test out your code to see if it works even in the all possible scenarios. Also, in case your code does break, you need to handle it gracefully and inform the user about what when wrong. In short, even in a mayday situation, your system must not shut down
Along with that, you also have to provide some sort of information about what your APIs are doing logically so that the users can understand how to use them. And there are also minor things like ensuring that your code follows good coding practices and standards ( There may be situations where your code can go under review and if the code quality is found to below par, it may smell trouble for you!)
All this will be covered within this series where we'll explore topics like handling errors, writing simple unit test cases for your APIs, generating documentation etc. Don't beat around....Head over to our first post to know how!