[MUSIC]

Hello and welcome back.

In this lecture, we will start off by looking at version control or

versioning your service.

Now it's quite obvious that once you have a service exposed,

you will make changes by adding more features or changes to your API.

And then when you make these changes, how do you make your services still

compatible with your older clients, right, people who are using older API.

How do you keep them happy?

So we'll talk about how to add additional vendor media type or basically

adding your V1 and V2 and V3, which is version one, two, three and so on.

And also focus on how to keep your service backward compatible, so

by adding a vendor media type, or by adding a version one or version two.

You're still keeping your new clients happy, and

also your old clients happy, because nothing is broken.

So we'll take a look at that with some examples.

So we've established the fact that versioning is very common

practice in the industry, right?

So in our example, we began this whole web services topic with

one single field called name for the actor.

But then as time evolved we decided, well we need, we have other clients who

are asking to break name into first_name and last_name, which makes sense when

you're building a model for an actor or an employee or a customer,

you really want to keep first name and last name, rather than combining the name.

So we said okay, we'll change our name to first_name and

last_name, which is exactly what we are doing here.

But by doing this, well what happens to name, right?

What happens to all the clients who are talking to us with name,

sending in the actors first name and last name concatenated,

and also expecting the name to be concatenated, right?

So we have to make sure that all those clients are still happy.

Plus we keep the new clients coming in with Derek Waterman is the first name and

last name, that's part of the model, keep them happy as well.

And that's exactly what this topic is, so we'll go and do the versioning here.

Well, to explain this problem a little bit, right, so

we have exposed our URI as actor/ID.json ,the format.

So when you do an actor/I00/json you will get an actor back.

Now,the problem is we never really began this problem or exercise with any kind

of versioning built into it right so we just said id.data will give you the id.

So now the problem is even though we have first name and

last name as part of the attributes, we never get that back because 100.json

at id will by default will give you back the name as the name of the actor.

There's no first name and last name broken apart.

So what we need to do is there are two approaches.

And we'll talk about that in a minute where you can either begin your project

as a good practice with a default version like we want and

then continue on that way.

Or, you stick with the fact that 100.json is your default, and

then for new clients coming in,

the first name and last name requirement, you give them a different URI.

So let's go and run this really quickly to see this one more time.

So this is what I was saying right?

When the clients make a request with the id you get the name.

There is no first name and last name broken apart.

You just get as a name.

Even though you do have first name and last name as part of the model.

So we can solve this problem by using vendor media type, VND.

So all we need to do is define a different media type format, and

we need to register this format within your application, and

you do that in your config intializer initializers/mime_types.rb.

So you go and define your application/vnd.

You know, your domain, like myorgmovies in this example, or it could be anything but

that's basically up to you.

And then .v2+json :v2json.

So I'll tell you where all this will come handy, but this is how you go and

Okay, so now you have access to both your v2, your version two,

which is your latest one, and also the old one, and again, if you do a MoviesWS.get,

if you hit that, URI V2json, you will get first name and last name, and

if you go back and just do a regular actors/100.json, you will get the old one.

So remember, as I was saying, you have either to solve this problem you either,

you start vljson from the start, where you'll have this as the default.

If not, just keep the one that you have as the default,

which is the json as the current version, and then any enhancements that you do,

if I go back, you' would start applying v2, and v3, and v4, and so on.

So let's go and try this example and

we should get different results depending on which URI we hit.

Okay, so let's go and hit our new URI v2json.

This is a new version, right?

It's an updated version.

So, we get a response back.

Well, let's go and actually look at the response body and

you should see, notice how we get a first name and a last name.

So we get the data back as expected.

So our old URI should still work, so all our old customers should still be happy.

So if I simply do 100.json I get the response OK.

If I do a response.body, then I should see name is Sylvester Stallone.

So notice how I got first_name and last_name here and

here we only got a name.

So this way, now you have a very important and

a powerful feature in your services where you can have multiple versions.

Okay, so just to summarize this topic,

as I said, things are bound to change within your application.

So always, it's a good practice to consider the versioning from the start.

Next topic, we will go and look at content negotiation and

we'll look at this with some good examples, thank you.

Versioning

Ruby on Rails Web Services and Integration with MongoDB

Meet the Instructors