So now that we've spoken about design, and we've spoken about documentation,
now let's start thinking about virtualization. So virtualization is
not a new concept, it's been around for a while, but it's kind of becoming a big
important piece in the API world. So what do I mean by virtualization? Right, so
today let's take the example of the fact that you're building an application and
you're building an API as part of that application. Now say in this case
this application this API which you're building actually interacts with the
Google Maps API. Now the Google Maps API, even though it's public, they
have rate limited their public API. Now in your system, when you actually want to,
when you're still in the development phase, you want to make sure that you're
testing these APIs for high load so you can't keep
hitting the publicly available Google API because remember they have a
rate limit and they will essentially be charging you once you hit that rate
limit. So this is just an example of course where now instead of using the
Google Maps public API you can actually virtualize the data which was supposed
to be hitting Google Maps. Instead, you can actually have the data locally
stored using some using virtualization and allow you to actually perform some
great comprehensive tests to your existing API. The other, of course,
example is instead of waiting for the backend scheme to go in and build out
the entire back-end logic for the front-end teams to start consuming them
you can actually have mock data. Once your definition is created so that
different teams can actually start working on this without any dependency
so this is just an example of service virtualization and it's not just seen in
APIs of course it's seen all across the board as I'm showing you devices, data
bases, networks, it's all over it's all over the place. So you know as I kind of
alluded to this but from the definition itself you can actually virtualize all
the different operations and the data points which your definition actually
specifies from which you develop. Your internal
stakeholders, like your developers ,your testers, they all can start understanding
what the API does and start working on their different job functions. The
developers, say for example the front-end developer, he or she knows exactly what
the data is supposed to be returned from that API so that they can start working
on the front end clients. The testers they can see they can understand the
requests and responses, they can get the dummy data and start writing test cases.
So that's just an example so it kind of minimizes dependencies and
allows them to develop a great API. There's another example where from the
virtualized API instead of waiting for the entire application to be created you
can actually send that to a consumer this especially third-party partner
based consumers who have a revenue arrangement with you,
and you can get early feedback from them on saying, "hey, does this API fit your
needs?" You can get that early feedback, you can iterate on that feedback in a
more -- in a very -- agile way and build out a solid API which everyone loves.
So virtualization has great advantages for your internal
stakeholders as well as your external third-party partners. Advantages:
reduces dependencies between teams, it allows you to work in parallel because
once you've reduced any dependencies different teams can actually start
working together simultaneously without much dependencies between them,
and finally of course faster prototyping. You can, since everyone is aligned on
what the data is supposed to be returned from the responses,
they can all start working simultaneously and that ensures a faster
go to market for your API as well. SmartBear specifically has a product called
service virtualization serviceV Pro and that allows you to do all of
these things: create virtual services really fast either locally or
on the cloud itself and really virtualize APIs and databases with
almost minimal almost little to nothing configuration item and primarily from
the definition that we're talking about primarily how these tools can actually
do it from the definition itself. So from your definition because you've specified
all the requests and responses there minimal configuration because that's
already been done in the definition itself