Should new API version supports all apis of older versions also ? [Design question]










2















I am having a set of apis exposed at base/api/v1/end-point1, base/api/v1/end-point2, base/api/v1/end-point3, etc. These are basically v1 apis.



Now we're moving on to expose v2 apis. In this new api version we'll add some new apis, refactor some existing (v1) apis and some apis will remain unaltered.



So my question is should I expose all the unaltered apis of v1 in v2 also ?




Example :



API V1:



api/v1/users - remains unaltered



api/v1/feature1 - will change



other end-points...



API V2:



api/v2/feature1 - refactored feature



api/v2/feature2 - newly added



api/v2/users - should I expose this also ?




I think:



I should not : because it's same



I should : because if it's not exposed then client will need to use different api versions(end-points) for different resources.



What are you doing ? What's your view ? Any reference any best practice resources will be much appreciated.



Let me know if this question is not apt for this platform. I'll happy to ask this at appropriate place.










share|improve this question

















  • 1





    In regards to REST not the API needs to be versioned but the media-types you exchange as they define the syntax and semantics of the payload exchanged. REST isn't about invoking methods, it's about resource state. If you look at HTML i.e., it was defined to be backwards compatible. So any client understanding HTML 5 does also understand the previous versions. For your RPC-esque view though, it is primarily your choice whether you want backwards compatability or not

    – Roman Vottner
    Nov 17 '18 at 14:38











  • Thanks for your comment @RomanVottner

    – Mohammad Umair
    Nov 18 '18 at 10:29















2















I am having a set of apis exposed at base/api/v1/end-point1, base/api/v1/end-point2, base/api/v1/end-point3, etc. These are basically v1 apis.



Now we're moving on to expose v2 apis. In this new api version we'll add some new apis, refactor some existing (v1) apis and some apis will remain unaltered.



So my question is should I expose all the unaltered apis of v1 in v2 also ?




Example :



API V1:



api/v1/users - remains unaltered



api/v1/feature1 - will change



other end-points...



API V2:



api/v2/feature1 - refactored feature



api/v2/feature2 - newly added



api/v2/users - should I expose this also ?




I think:



I should not : because it's same



I should : because if it's not exposed then client will need to use different api versions(end-points) for different resources.



What are you doing ? What's your view ? Any reference any best practice resources will be much appreciated.



Let me know if this question is not apt for this platform. I'll happy to ask this at appropriate place.










share|improve this question

















  • 1





    In regards to REST not the API needs to be versioned but the media-types you exchange as they define the syntax and semantics of the payload exchanged. REST isn't about invoking methods, it's about resource state. If you look at HTML i.e., it was defined to be backwards compatible. So any client understanding HTML 5 does also understand the previous versions. For your RPC-esque view though, it is primarily your choice whether you want backwards compatability or not

    – Roman Vottner
    Nov 17 '18 at 14:38











  • Thanks for your comment @RomanVottner

    – Mohammad Umair
    Nov 18 '18 at 10:29













2












2








2








I am having a set of apis exposed at base/api/v1/end-point1, base/api/v1/end-point2, base/api/v1/end-point3, etc. These are basically v1 apis.



Now we're moving on to expose v2 apis. In this new api version we'll add some new apis, refactor some existing (v1) apis and some apis will remain unaltered.



So my question is should I expose all the unaltered apis of v1 in v2 also ?




Example :



API V1:



api/v1/users - remains unaltered



api/v1/feature1 - will change



other end-points...



API V2:



api/v2/feature1 - refactored feature



api/v2/feature2 - newly added



api/v2/users - should I expose this also ?




I think:



I should not : because it's same



I should : because if it's not exposed then client will need to use different api versions(end-points) for different resources.



What are you doing ? What's your view ? Any reference any best practice resources will be much appreciated.



Let me know if this question is not apt for this platform. I'll happy to ask this at appropriate place.










share|improve this question














I am having a set of apis exposed at base/api/v1/end-point1, base/api/v1/end-point2, base/api/v1/end-point3, etc. These are basically v1 apis.



Now we're moving on to expose v2 apis. In this new api version we'll add some new apis, refactor some existing (v1) apis and some apis will remain unaltered.



So my question is should I expose all the unaltered apis of v1 in v2 also ?




Example :



API V1:



api/v1/users - remains unaltered



api/v1/feature1 - will change



other end-points...



API V2:



api/v2/feature1 - refactored feature



api/v2/feature2 - newly added



api/v2/users - should I expose this also ?




I think:



I should not : because it's same



I should : because if it's not exposed then client will need to use different api versions(end-points) for different resources.



What are you doing ? What's your view ? Any reference any best practice resources will be much appreciated.



Let me know if this question is not apt for this platform. I'll happy to ask this at appropriate place.







rest django-rest-framework api-design






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 16 '18 at 7:18









Mohammad UmairMohammad Umair

2,2031721




2,2031721







  • 1





    In regards to REST not the API needs to be versioned but the media-types you exchange as they define the syntax and semantics of the payload exchanged. REST isn't about invoking methods, it's about resource state. If you look at HTML i.e., it was defined to be backwards compatible. So any client understanding HTML 5 does also understand the previous versions. For your RPC-esque view though, it is primarily your choice whether you want backwards compatability or not

    – Roman Vottner
    Nov 17 '18 at 14:38











  • Thanks for your comment @RomanVottner

    – Mohammad Umair
    Nov 18 '18 at 10:29












  • 1





    In regards to REST not the API needs to be versioned but the media-types you exchange as they define the syntax and semantics of the payload exchanged. REST isn't about invoking methods, it's about resource state. If you look at HTML i.e., it was defined to be backwards compatible. So any client understanding HTML 5 does also understand the previous versions. For your RPC-esque view though, it is primarily your choice whether you want backwards compatability or not

    – Roman Vottner
    Nov 17 '18 at 14:38











  • Thanks for your comment @RomanVottner

    – Mohammad Umair
    Nov 18 '18 at 10:29







1




1





In regards to REST not the API needs to be versioned but the media-types you exchange as they define the syntax and semantics of the payload exchanged. REST isn't about invoking methods, it's about resource state. If you look at HTML i.e., it was defined to be backwards compatible. So any client understanding HTML 5 does also understand the previous versions. For your RPC-esque view though, it is primarily your choice whether you want backwards compatability or not

– Roman Vottner
Nov 17 '18 at 14:38





In regards to REST not the API needs to be versioned but the media-types you exchange as they define the syntax and semantics of the payload exchanged. REST isn't about invoking methods, it's about resource state. If you look at HTML i.e., it was defined to be backwards compatible. So any client understanding HTML 5 does also understand the previous versions. For your RPC-esque view though, it is primarily your choice whether you want backwards compatability or not

– Roman Vottner
Nov 17 '18 at 14:38













Thanks for your comment @RomanVottner

– Mohammad Umair
Nov 18 '18 at 10:29





Thanks for your comment @RomanVottner

– Mohammad Umair
Nov 18 '18 at 10:29












1 Answer
1






active

oldest

votes


















2














Yes.



Each version should be independent of other. The rationale is that once a version of API is released to the public, it is going to behave the same till it gets deprecated. This ensures that the API provided are stable and doesn't break with a different response. Also from an end developer perspective who consumes the API, it is clean and doesn't confuse about remembering multiple versions.



We usually have multiple versioning as mentioned in SEMVER docs




Given a version number MAJOR.MINOR.PATCH, increment the:



MAJOR version when you make incompatible API changes



MINOR version when you add functionality in a backwards-compatible manner, and



PATCH version when you make backwards-compatible bug fixes.







share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function ()
    StackExchange.using("externalEditor", function ()
    StackExchange.using("snippets", function ()
    StackExchange.snippets.init();
    );
    );
    , "code-snippets");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "1"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53333147%2fshould-new-api-version-supports-all-apis-of-older-versions-also-design-questi%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    2














    Yes.



    Each version should be independent of other. The rationale is that once a version of API is released to the public, it is going to behave the same till it gets deprecated. This ensures that the API provided are stable and doesn't break with a different response. Also from an end developer perspective who consumes the API, it is clean and doesn't confuse about remembering multiple versions.



    We usually have multiple versioning as mentioned in SEMVER docs




    Given a version number MAJOR.MINOR.PATCH, increment the:



    MAJOR version when you make incompatible API changes



    MINOR version when you add functionality in a backwards-compatible manner, and



    PATCH version when you make backwards-compatible bug fixes.







    share|improve this answer



























      2














      Yes.



      Each version should be independent of other. The rationale is that once a version of API is released to the public, it is going to behave the same till it gets deprecated. This ensures that the API provided are stable and doesn't break with a different response. Also from an end developer perspective who consumes the API, it is clean and doesn't confuse about remembering multiple versions.



      We usually have multiple versioning as mentioned in SEMVER docs




      Given a version number MAJOR.MINOR.PATCH, increment the:



      MAJOR version when you make incompatible API changes



      MINOR version when you add functionality in a backwards-compatible manner, and



      PATCH version when you make backwards-compatible bug fixes.







      share|improve this answer

























        2












        2








        2







        Yes.



        Each version should be independent of other. The rationale is that once a version of API is released to the public, it is going to behave the same till it gets deprecated. This ensures that the API provided are stable and doesn't break with a different response. Also from an end developer perspective who consumes the API, it is clean and doesn't confuse about remembering multiple versions.



        We usually have multiple versioning as mentioned in SEMVER docs




        Given a version number MAJOR.MINOR.PATCH, increment the:



        MAJOR version when you make incompatible API changes



        MINOR version when you add functionality in a backwards-compatible manner, and



        PATCH version when you make backwards-compatible bug fixes.







        share|improve this answer













        Yes.



        Each version should be independent of other. The rationale is that once a version of API is released to the public, it is going to behave the same till it gets deprecated. This ensures that the API provided are stable and doesn't break with a different response. Also from an end developer perspective who consumes the API, it is clean and doesn't confuse about remembering multiple versions.



        We usually have multiple versioning as mentioned in SEMVER docs




        Given a version number MAJOR.MINOR.PATCH, increment the:



        MAJOR version when you make incompatible API changes



        MINOR version when you add functionality in a backwards-compatible manner, and



        PATCH version when you make backwards-compatible bug fixes.








        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 17 '18 at 11:13









        BharathwaajBharathwaaj

        1,65711631




        1,65711631





























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53333147%2fshould-new-api-version-supports-all-apis-of-older-versions-also-design-questi%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Top Tejano songwriter Luis Silva dead of heart attack at 64

            政党

            天津地下鉄3号線