We had an offline discussion with Azeez and Sameera on this issue.
Following points were discussed.
- Microservices will not required to maintain a version number in its
path. Version number of an API is a metadata information, which need to
maintain separately. Best option is to use swagger annotations for this.
- Maintaining several version of same API in a single product is
cumbersome and will be difficult maintain. Hence every time we will expose
only one versions of the API in a product.
- Best way to expose different versions of same API is to have different
versions of the product
and use API gateway
to
rout
e
to the correct
product
instances
which expose correct API implementation
.
- W
hen there is an API addition or change
,
v
ersion number has to increment.
Please add If I missed anything.
Thanks,
Hasitha.
On Thu, May 5, 2016 at 2:17 PM, Afkham Azeez <[email protected]> wrote:
> In what cases would you require to maintain multiple versions of a
> microservice in a product? Or is this related to different versions of the
> same product? If it is the second case, it is the responsibility of the
> gateway to route to the correct instances and there is no need to maintain
> version information on the product runtime side.
>
> On Thu, May 5, 2016 at 2:12 PM, Sameera Jayasoma <[email protected]> wrote:
>
>>
>>
>> On Thu, May 5, 2016 at 12:42 PM, Hasitha Aravinda <[email protected]>
>> wrote:
>>
>>> Some more questions
>>>
>>> On Thu, May 5, 2016 at 12:30 PM, Sameera Jayasoma <[email protected]>
>>> wrote:
>>>
>>>> I believe its wrong to use the product version to version your micro
>>>> services.
>>>>
>>>> You need to have different version for your microservices. e.g.
>>>> starting from 1.0.0. If you don't change any of your microservices you
>>>> shouldn't be changing these versions.
>>>>
>>>
>>> According to Rest API guideline, it should be product version. isn't
>>> it ?
>>>
>>
>> We cannot change API versions for each and every product release. You
>> should change the API version only if you have introduced a change. We are
>> following the same approach to version export packages from bundles.
>>
>>
>>>
>>> Let's say we are using version from 1.0.0.
>>> If we are going to do a modification
>>>
>>> to a microservice ( let's say foo 1.0) and new version is foo 1.1 Do
>>> we need to maintain both versions to provide backward compatibility ? If so
>>> we have to maintain two microservices: Foo 1.0 and Foo 1.1, because version
>>> is a part of the path in microservice.
>>>
>>
>> I am not sure whether need to maintain the previous versions of micro
>> services. Thats something we need to discuss. Also it adds complexity.
>>
>> If you have introduced any additions to your micro services, then you can
>> bump up the minor version number. If you've introduced incompatible
>> changes, then you have bump up the major version number.
>>
>>
>>
>>>
>>> eg:
>>> @Path("
>>> /bps/bpmn/v
>>> 1
>>> .0/
>>> foo
>>> ")
>>> ,
>>> @Path("
>>> /bps/bpmn/v
>>> 1
>>> .
>>> 1
>>> /
>>> foo
>>> ")
>>>
>>> Thanks,
>>> Hasitha.
>>>
>>>
>>>> On Thu, May 5, 2016 at 11:02 AM, Himasha Guruge <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> We have refactored our REST APIs by implementing Microservice
>>>>> interface. According to the new REST guideline , we need to maintain the
>>>>> URL format like below. For example,
>>>>>
>>>>> http://localhost:7777/bps/bpmn/v4.0/repository/deployments
>>>>>
>>>>> How are we going to maintain the product version updates with
>>>>> microservices? If we are to maintain the product version with a parameter
>>>>> been set from a config file, how can we achieve this?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Himasha Guruge
>>>>> *Software Engineer*
>>>>> WS*O2* *Inc.*
>>>>> Mobile: +94 777459299
>>>>> [email protected]
>>>>>
>>>>> _______________________________________________
>>>>> Architecture mailing list
>>>>> [email protected]
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sameera Jayasoma,
>>>> Software Architect,
>>>>
>>>> WSO2, Inc. (http://wso2.com)
>>>> email: [email protected]
>>>> blog: http://blog.sameera.org
>>>> twitter: https://twitter.com/sameerajayasoma
>>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
>>>> Mobile: 0094776364456
>>>>
>>>> Lean . Enterprise . Middleware
>>>>
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Hasitha Aravinda,
>>> Senior Software Engineer,
>>> WSO2 Inc.
>>> Email: [email protected]
>>> Mobile : +94 718 210 200
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Sameera Jayasoma,
>> Software Architect,
>>
>> WSO2, Inc. (http://wso2.com)
>> email: [email protected]
>> blog: http://blog.sameera.org
>> twitter: https://twitter.com/sameerajayasoma
>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections
>> Mobile: 0094776364456
>>
>> Lean . Enterprise . Middleware
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * <http://www.apache.org/>*
> *email: **[email protected]* <[email protected]>
> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
> *http://blog.afkham.org* <http://blog.afkham.org>
> *twitter: **http://twitter.com/afkham_azeez*
> <http://twitter.com/afkham_azeez>
> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
> <http://lk.linkedin.com/in/afkhamazeez>*
>
> *Lean . Enterprise . Middleware*
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
--
Hasitha Aravinda,
Senior Software Engineer,
WSO2 Inc.
Email: [email protected]
Mobile : +94 718 210 200
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
