0

Recently working on a ASPCore Web Api (C#) I wanted to add a version endpoint so I can tell which version of a given API Im working with. Its a public API so I don't want to include things that might be used to determine vulnerabilities such as third party package version etc. So far I've got the Following.

    // GET api/values
    [HttpGet]
    public string Get()
    {
        var attributes = Assembly.GetEntryAssembly().CustomAttributes;
        string versionInfo=null;
        foreach(var attribute in attributes)
        {
            if (attribute.AttributeType.Name.StartsWith("Assembly")&& attribute.AttributeType.Name.EndsWith("Attribute"))
            {
                string name = attribute.AttributeType.Name;
                name = name.Substring(8, name.Length - 17);
                versionInfo = string.Concat(versionInfo, name, ":");
                versionInfo = string.Concat(versionInfo, attribute.ConstructorArguments.FirstOrDefault());
                versionInfo = string.Concat(versionInfo, System.Environment.NewLine);
            }
        }
        return versionInfo;
    }

which Produces

Company:"Company Name"
Configuration:"Debug"
Description:"Package Description"
FileVersion:"0.0.1.0"
InformationalVersion:"0.0.1"
Product:"ProductName"
Title:"PackageTitle"

Is there any more industry standard approach to this. Seems it would be a fairly standard issue but Im not seeing any sort of standard way to accomplish this from my brief date with Google.

David
  • 1,131
  • 9
  • 22
  • See [here](https://stackoverflow.com/questions/389169/best-practices-for-api-versioning) for a good discussion of this topic. Basic options are use the URL (not RESTful), stick the version in a header, don't version (means code for backwards compat and create a new endpoint for a breaking change). – Matt Jul 03 '17 at 09:02
  • Hmm looks like the answer to my question then is No. Bit surprising that after 9 years there is still no defined standard. – David Jul 03 '17 at 15:15
  • Well I think there is effectively more than one common way to do things, but certainly no "industry standard" as such. The "don't version" option I would say is certainly becoming a best practice, look up HATEOS for more related info on that. – Matt Jul 03 '17 at 15:32
  • Don't Version Im afraid is a pipe dream. Every time you make a change to a code base its a new version. Even if it is 100% backwards compatable with additional endpoints injected via a new assembly ... its still a new version but thats a different discussion thanks for the reply. – David Jul 04 '17 at 01:57
  • Well of course every time you make a change to the backend you will want to version that, I'm talking about versioning the REST API itself and more generally I'm talking about designing and extending your API in a way that doesn't break existing clients. See [here](https://www.mnot.net/blog/2011/10/25/web_api_versioning_smackdown), [here](https://www.slideshare.net/evolve_conference/201308-fielding-evolve/31) and [here](http://www.ben-morris.com/rest-apis-dont-need-a-versioning-strategy-they-need-a-change-strategy/). – Matt Jul 04 '17 at 13:38
  • Right I understand that and my desire is to display which of those various versions is currently active in Production, Uat and development. Your referring to how to properly develop an API thats not really what Im asking about. Im asking how to currently expose to the end user which version they are on... reguardless of how it might be developed. – David Jul 06 '17 at 01:35
  • As we've already stated there is no standard at this time so any further discussion is really just that and not really appropriate for SO comments. Hopefully someday a standard will be created and someone can then answer this question. – David Jul 06 '17 at 01:43

0 Answers0