Version implementation planning - Claude Tutorial

- [Instructor] Like I mentioned, there is no one way of versioning your APIs. I tend to like more about the custom HTTP header and I know some of the benefits, but not all, which is where I'm going to ask follow-up question to drill down more into this URL scheme and find out if there is more to it. So I'm going to ask a follow-up question and my prompt is here. I'm telling it that I like custom header scheme because it provides a way to create production version such as this and preview versions. So the benefit that you get with having the custom version headers is that your API consumers can use two different versions at the same time and you can have two different versions of your APIs working at the same time in production. This is one of the biggest benefits that I like. You have a production version and then you have a new upcoming version that you are opening up for the world to use. But more than that there are more benefits and I am giving example that Azure uses this scheme and I want Claude to explain this scheme and its benefits and that's why I'm putting or keeping the option as explanatory. So I'm going to hit send. The first benefit it has already outlined as you have discussed, that we can have a production version and then we can have, which was in 25th of December, 2024. And then there is upcoming release planned on 2nd of February, 2025 in future. And that's why it is marked as preview, but they both are values under the same error and that's one of the big benefits that we get. And it's showing how you can use the different API versions with the same API URL. So it creates a natural progression as you mentioned, of upgrading your APIs to ensure that the current production version is working as expected and the newer version is evolving as per the expectation as well. So secondary, it provides the temporal context, which means by looking at this scheme, you know when this API release happened or the behavior was released at what version and when a new version is released, you know what changes it is coming and when it is due. So things like that are some of the benefits of using the custom header scheme. So it is outlining all of those benefits. Now, since I'm convinced, I wanted to show you that Claude has similar ways of explaining the core concept behind the SJTP header scheme. I'm now convinced and I want to share this with my team members so that when they implement this versioning scheme, they have context of what options we have chosen, how it works, and all of those things. So that takes me to the next step wherein we need to create the artifact so that when we share this with our developers, they have enough context on how to implement it. So now I'm going to paste another prompt that I have already prepared and I will review it with you. So I'm saying that considering that we are taking the custom header approach, so we have finalized that I want Claude to create the mark on artifact. That includes two things, the overview for this custom header scheme and the benefits of custom headers. Now additionally, I want one benefit, one section and examples within that. This helps to underscore the bullet points of the benefits and for each benefit give enough information when developers actually read the documentation. So I'm going to hit send now. The API versioning documentation is getting ready. So as you may see, we are getting bullet points with numbers, which is benefits per section and examples within that. So I will let it complete. Great, so as I go up, it gives me an overview of how the xAPI versions are identified, how to make the request, and then the benefits, which is first is clean and restful URLs. The second one is temporal context and clarity on what version number, what feature was released. Parallel preview production tracks, which means the production version is working fine, but you can encourage your API consumers to try out the preview versions and give feedback at the same time in the same environment. The third one is the granular version control, which means you can tell that which version is current, which one is supported, which is deprecated, and which one is in preview, and the context of different version numbers and it enhances the document and communication with the teams. And finally it tells that you also have the facility of flexible feature management, so you can create a feature map like this. If this is the release version, you can have bulk upload through advanced pricing falls. So these could be different features and within these versions you can toggle on or off certain features of your applications. Then you have simplified caching strategies and best practices. And finally it gives an implementation example, which is really useful for the developers on your team to identify how to make API calls when custom version header is involved. So this looks like a comprehensive document that I would like to share with my developer team so that they can understand how this is implemented, what are the benefits, and why we are taking this approach. Finally, if you're happy with the document, like any other document I have downloaded so far, I'm going to click download and save it so that I can share this with my team members when I'm ready to import this into other tools.