[Proposal] Introducing the version in REST API URI for kimchi/ginger plugins
Hi Kimchi/Ginger Devel-Team, Thank you for creating WOK branch to separate the kimchi plugin from the base frame work. It is a great idea. Along with the separation of kimchi plugin looks like there is a transformation of REST API URIs as well. So thinking in those lines will it be good idea even to introduce version to the REST API URIs ? Let me take one REST API URI to convey clear on what I am talking about. To retrieve the host repository information, current URI is: "/plugins/kimchi/host/repositories". Recommendation: New host repository URI can look like : " /plugins/kimchi/v<version>/host/repositories" , so that it is easy to maintain REST API future enhancements at the same time do not brake some body who is using the existing URI. Note* Adding version in the URI above is just an example and we could place the version in the URI best possible way. Thanks and Regards, Chandra Shekhar Reddy Potula Staff System Software Engineer IBM Systems & Technology Group, Systems Software Development System z Firmware Development Phone: 91-080-4066-0786 | Mobile: 91-973-1122-221 IBM E-mail: chandra.shekhar@in.ibm.com ORR, Manyatha MD3 1F B247 Bengaluru, Karnataka 560045 India
Hi Chandra, I don't see any benefit in adding the version in the URL. Instead of that, it scares me on how we will maintain it. Once we move to wok and Kimchi as plugin, all the APIs will be automatically updated so everything will be in the same page. Regards, Aline Manera On 17/07/2015 09:47, Chandra Sr Potula wrote:
Hi Kimchi/Ginger Devel-Team,
Thank you for creating WOK branch to separate the kimchi plugin from the base frame work. It is a great idea.
Along with the separation of kimchi plugin looks like there is a transformation of REST API URIs as well. So thinking in those lines will it be good idea even to introduce version to the REST API URIs ?
Let me take one REST API URI to convey clear on what I am talking about.
To retrieve the host repository information, current URI is: "/plugins/kimchi/host/repositories".
*Recommendation*: New host repository URI can look like : *"**/plugins/kimchi/v<version>/host/repositories" , *so that it is easy to maintain REST API future enhancements at the same time do not brake some body who is using the existing URI.
Note* Adding version in the URI above is just an example and we could place the version in the URI best possible way.
Thanks and Regards, *Chandra Shekhar Reddy Potula* Staff System Software Engineer IBM Systems & Technology Group, Systems Software Development System z Firmware Development ------------------------------------------------------------------------ *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221* E-mail:*_chandra.shekhar@in.ibm.com_ <mailto:chandra.shekhar@in.ibm.com> IBM
ORR, Manyatha MD3 1F B247 Bengaluru, Karnataka 560045 India
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi Aline, Versioning helps you iterate faster and prevents invalid requests from hitting updated endpoints. It also helps smooth transitions over any major API version as you can continue to offer old API versions for a period of time. Definitely supporting the old version of API period of time while offering new functionality with newer version always give benefits and extra time for end user to adjust to new one. I see lot of products in the market are adapting versioning (see below link) http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/ I do understand the concern of maintaining the version of the API endpoints , below are some of the links from Openstack, which talks about it. http://developer.openstack.org/api-ref.html https://wiki.openstack.org/wiki/VersionDiscovery Hope it make senses to you. Regards Chandra On 08/06/2015 12:04 AM, Aline Manera wrote:
Hi Chandra,
I don't see any benefit in adding the version in the URL. Instead of that, it scares me on how we will maintain it.
Once we move to wok and Kimchi as plugin, all the APIs will be automatically updated so everything will be in the same page.
Regards, Aline Manera
On 17/07/2015 09:47, Chandra Sr Potula wrote:
Hi Kimchi/Ginger Devel-Team,
Thank you for creating WOK branch to separate the kimchi plugin from the base frame work. It is a great idea.
Along with the separation of kimchi plugin looks like there is a transformation of REST API URIs as well. So thinking in those lines will it be good idea even to introduce version to the REST API URIs ?
Let me take one REST API URI to convey clear on what I am talking about.
To retrieve the host repository information, current URI is: "/plugins/kimchi/host/repositories".
*Recommendation*: New host repository URI can look like : *"**/plugins/kimchi/v<version>/host/repositories" , *so that it is easy to maintain REST API future enhancements at the same time do not brake some body who is using the existing URI.
Note* Adding version in the URI above is just an example and we could place the version in the URI best possible way.
Thanks and Regards, *Chandra Shekhar Reddy Potula* Staff System Software Engineer IBM Systems & Technology Group, Systems Software Development System z Firmware Development ------------------------------------------------------------------------ *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221* E-mail:*_chandra.shekhar@in.ibm.com_ <mailto:chandra.shekhar@in.ibm.com> IBM
ORR, Manyatha MD3 1F B247 Bengaluru, Karnataka 560045 India
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Hi Aline, No need to mention explicitly, but this is very useful in case where end users are exploiting functionality via REST API directly and not UI way. Regards Chandra On 08/06/2015 01:52 PM, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
Versioning helps you iterate faster and prevents invalid requests from hitting updated endpoints. It also helps smooth transitions over any major API version as you can continue to offer old API versions for a period of time. Definitely supporting the old version of API period of time while offering new functionality with newer version always give benefits and extra time for end user to adjust to new one.
I see lot of products in the market are adapting versioning (see below link) http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
I do understand the concern of maintaining the version of the API endpoints , below are some of the links from Openstack, which talks about it. http://developer.openstack.org/api-ref.html https://wiki.openstack.org/wiki/VersionDiscovery
Hope it make senses to you.
Regards Chandra
On 08/06/2015 12:04 AM, Aline Manera wrote:
Hi Chandra,
I don't see any benefit in adding the version in the URL. Instead of that, it scares me on how we will maintain it.
Once we move to wok and Kimchi as plugin, all the APIs will be automatically updated so everything will be in the same page.
Regards, Aline Manera
On 17/07/2015 09:47, Chandra Sr Potula wrote:
Hi Kimchi/Ginger Devel-Team,
Thank you for creating WOK branch to separate the kimchi plugin from the base frame work. It is a great idea.
Along with the separation of kimchi plugin looks like there is a transformation of REST API URIs as well. So thinking in those lines will it be good idea even to introduce version to the REST API URIs ?
Let me take one REST API URI to convey clear on what I am talking about.
To retrieve the host repository information, current URI is: "/plugins/kimchi/host/repositories".
*Recommendation*: New host repository URI can look like : *"**/plugins/kimchi/v<version>/host/repositories" , *so that it is easy to maintain REST API future enhancements at the same time do not brake some body who is using the existing URI.
Note* Adding version in the URI above is just an example and we could place the version in the URI best possible way.
Thanks and Regards, *Chandra Shekhar Reddy Potula* Staff System Software Engineer IBM Systems & Technology Group, Systems Software Development System z Firmware Development ------------------------------------------------------------------------ *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221* E-mail:*_chandra.shekhar@in.ibm.com_ <mailto:chandra.shekhar@in.ibm.com> IBM
ORR, Manyatha MD3 1F B247 Bengaluru, Karnataka 560045 India
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 06/08/2015 07:41, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
No need to mention explicitly, but this is very useful in case where end users are exploiting functionality via REST API directly and not UI way.
I suppose end users know which version he/she is using, right? =)
Regards Chandra
On 08/06/2015 01:52 PM, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
Versioning helps you iterate faster and prevents invalid requests from hitting updated endpoints. It also helps smooth transitions over any major API version as you can continue to offer old API versions for a period of time. Definitely supporting the old version of API period of time while offering new functionality with newer version always give benefits and extra time for end user to adjust to new one.
I see lot of products in the market are adapting versioning (see below link) http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
I do understand the concern of maintaining the version of the API endpoints , below are some of the links from Openstack, which talks about it. http://developer.openstack.org/api-ref.html https://wiki.openstack.org/wiki/VersionDiscovery
Hope it make senses to you.
Regards Chandra
On 08/06/2015 12:04 AM, Aline Manera wrote:
Hi Chandra,
I don't see any benefit in adding the version in the URL. Instead of that, it scares me on how we will maintain it.
Once we move to wok and Kimchi as plugin, all the APIs will be automatically updated so everything will be in the same page.
Regards, Aline Manera
On 17/07/2015 09:47, Chandra Sr Potula wrote:
Hi Kimchi/Ginger Devel-Team,
Thank you for creating WOK branch to separate the kimchi plugin from the base frame work. It is a great idea.
Along with the separation of kimchi plugin looks like there is a transformation of REST API URIs as well. So thinking in those lines will it be good idea even to introduce version to the REST API URIs ?
Let me take one REST API URI to convey clear on what I am talking about.
To retrieve the host repository information, current URI is: "/plugins/kimchi/host/repositories".
*Recommendation*: New host repository URI can look like : *"**/plugins/kimchi/v<version>/host/repositories" , *so that it is easy to maintain REST API future enhancements at the same time do not brake some body who is using the existing URI.
Note* Adding version in the URI above is just an example and we could place the version in the URI best possible way.
Thanks and Regards, *Chandra Shekhar Reddy Potula* Staff System Software Engineer IBM Systems & Technology Group, Systems Software Development System z Firmware Development ------------------------------------------------------------------------ *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221* E-mail:*_chandra.shekhar@in.ibm.com_ <mailto:chandra.shekhar@in.ibm.com> IBM
ORR, Manyatha MD3 1F B247 Bengaluru, Karnataka 560045 India
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
Aline, As an end user I might not like switching the URI quite often as developer keep changing them. It really defeat the purpose. Regards Chandra On 08/07/2015 12:03 AM, Aline Manera wrote:
On 06/08/2015 07:41, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
No need to mention explicitly, but this is very useful in case where end users are exploiting functionality via REST API directly and not UI way.
I suppose end users know which version he/she is using, right? =)
Regards Chandra
On 08/06/2015 01:52 PM, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
Versioning helps you iterate faster and prevents invalid requests from hitting updated endpoints. It also helps smooth transitions over any major API version as you can continue to offer old API versions for a period of time. Definitely supporting the old version of API period of time while offering new functionality with newer version always give benefits and extra time for end user to adjust to new one.
I see lot of products in the market are adapting versioning (see below link) http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
I do understand the concern of maintaining the version of the API endpoints , below are some of the links from Openstack, which talks about it. http://developer.openstack.org/api-ref.html https://wiki.openstack.org/wiki/VersionDiscovery
Hope it make senses to you.
Regards Chandra
On 08/06/2015 12:04 AM, Aline Manera wrote:
Hi Chandra,
I don't see any benefit in adding the version in the URL. Instead of that, it scares me on how we will maintain it.
Once we move to wok and Kimchi as plugin, all the APIs will be automatically updated so everything will be in the same page.
Regards, Aline Manera
On 17/07/2015 09:47, Chandra Sr Potula wrote:
Hi Kimchi/Ginger Devel-Team,
Thank you for creating WOK branch to separate the kimchi plugin from the base frame work. It is a great idea.
Along with the separation of kimchi plugin looks like there is a transformation of REST API URIs as well. So thinking in those lines will it be good idea even to introduce version to the REST API URIs ?
Let me take one REST API URI to convey clear on what I am talking about.
To retrieve the host repository information, current URI is: "/plugins/kimchi/host/repositories".
*Recommendation*: New host repository URI can look like : *"**/plugins/kimchi/v<version>/host/repositories" , *so that it is easy to maintain REST API future enhancements at the same time do not brake some body who is using the existing URI.
Note* Adding version in the URI above is just an example and we could place the version in the URI best possible way.
Thanks and Regards, *Chandra Shekhar Reddy Potula* Staff System Software Engineer IBM Systems & Technology Group, Systems Software Development System z Firmware Development ------------------------------------------------------------------------ *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221* E-mail:*_chandra.shekhar@in.ibm.com_ <mailto:chandra.shekhar@in.ibm.com> IBM
ORR, Manyatha MD3 1F B247 Bengaluru, Karnataka 560045 India
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/08/2015 02:19, Chandra Shehkhar Reddy Potula wrote:
Aline,
As an end user I might not like switching the URI quite often as developer keep changing them. It really defeat the purpose.
So do not update to a newer version!
Regards Chandra
On 08/07/2015 12:03 AM, Aline Manera wrote:
On 06/08/2015 07:41, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
No need to mention explicitly, but this is very useful in case where end users are exploiting functionality via REST API directly and not UI way.
I suppose end users know which version he/she is using, right? =)
Regards Chandra
On 08/06/2015 01:52 PM, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
Versioning helps you iterate faster and prevents invalid requests from hitting updated endpoints. It also helps smooth transitions over any major API version as you can continue to offer old API versions for a period of time. Definitely supporting the old version of API period of time while offering new functionality with newer version always give benefits and extra time for end user to adjust to new one.
I see lot of products in the market are adapting versioning (see below link) http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
I do understand the concern of maintaining the version of the API endpoints , below are some of the links from Openstack, which talks about it. http://developer.openstack.org/api-ref.html https://wiki.openstack.org/wiki/VersionDiscovery
Hope it make senses to you.
Regards Chandra
On 08/06/2015 12:04 AM, Aline Manera wrote:
Hi Chandra,
I don't see any benefit in adding the version in the URL. Instead of that, it scares me on how we will maintain it.
Once we move to wok and Kimchi as plugin, all the APIs will be automatically updated so everything will be in the same page.
Regards, Aline Manera
On 17/07/2015 09:47, Chandra Sr Potula wrote:
Hi Kimchi/Ginger Devel-Team,
Thank you for creating WOK branch to separate the kimchi plugin from the base frame work. It is a great idea.
Along with the separation of kimchi plugin looks like there is a transformation of REST API URIs as well. So thinking in those lines will it be good idea even to introduce version to the REST API URIs ?
Let me take one REST API URI to convey clear on what I am talking about.
To retrieve the host repository information, current URI is: "/plugins/kimchi/host/repositories".
*Recommendation*: New host repository URI can look like : *"**/plugins/kimchi/v<version>/host/repositories" , *so that it is easy to maintain REST API future enhancements at the same time do not brake some body who is using the existing URI.
Note* Adding version in the URI above is just an example and we could place the version in the URI best possible way.
Thanks and Regards, *Chandra Shekhar Reddy Potula* Staff System Software Engineer IBM Systems & Technology Group, Systems Software Development System z Firmware Development ------------------------------------------------------------------------ *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221* E-mail:*_chandra.shekhar@in.ibm.com_ IBM
ORR, Manyatha MD3 1F B247 Bengaluru, Karnataka 560045 India
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 08/07/2015 07:04 PM, Aline Manera wrote:
On 07/08/2015 02:19, Chandra Shehkhar Reddy Potula wrote:
Aline,
As an end user I might not like switching the URI quite often as developer keep changing them. It really defeat the purpose.
So do not update to a newer version!
I feel this may not be the right way to do if we want smooth transition to the end user. End user can still use the old functionality of certain feature's but at the same time seamlessly pick up the functionality released in the new version for other feature's !
Regards Chandra
On 08/07/2015 12:03 AM, Aline Manera wrote:
On 06/08/2015 07:41, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
No need to mention explicitly, but this is very useful in case where end users are exploiting functionality via REST API directly and not UI way.
I suppose end users know which version he/she is using, right? =)
Regards Chandra
On 08/06/2015 01:52 PM, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
Versioning helps you iterate faster and prevents invalid requests from hitting updated endpoints. It also helps smooth transitions over any major API version as you can continue to offer old API versions for a period of time. Definitely supporting the old version of API period of time while offering new functionality with newer version always give benefits and extra time for end user to adjust to new one.
I see lot of products in the market are adapting versioning (see below link) http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
I do understand the concern of maintaining the version of the API endpoints , below are some of the links from Openstack, which talks about it. http://developer.openstack.org/api-ref.html https://wiki.openstack.org/wiki/VersionDiscovery
Hope it make senses to you.
Regards Chandra
On 08/06/2015 12:04 AM, Aline Manera wrote:
Hi Chandra,
I don't see any benefit in adding the version in the URL. Instead of that, it scares me on how we will maintain it.
Once we move to wok and Kimchi as plugin, all the APIs will be automatically updated so everything will be in the same page.
Regards, Aline Manera
On 17/07/2015 09:47, Chandra Sr Potula wrote: > > Hi Kimchi/Ginger Devel-Team, > > Thank you for creating WOK branch to separate the kimchi plugin > from the base frame work. It is a great idea. > > Along with the separation of kimchi plugin looks like there is a > transformation of REST API URIs as well. So thinking in those > lines will it be good idea even to introduce version to the REST > API URIs ? > > Let me take one REST API URI to convey clear on what I am > talking about. > > To retrieve the host repository information, current URI is: > "/plugins/kimchi/host/repositories". > > *Recommendation*: > New host repository URI can look like : > *"**/plugins/kimchi/v<version>/host/repositories" , *so that it > is easy to maintain REST API future enhancements at the same > time do not brake some body who is using the existing URI. > > Note* Adding version in the URI above is just an example and we > could place the version in the URI best possible way. > > Thanks and Regards, > *Chandra Shekhar Reddy Potula* > Staff System Software Engineer > IBM Systems & Technology Group, Systems Software Development > System z Firmware Development > ------------------------------------------------------------------------ > *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221* > E-mail:*_chandra.shekhar@in.ibm.com_ > IBM > > ORR, Manyatha MD3 1F B247 > Bengaluru, Karnataka 560045 > India > > > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 06/08/2015 05:22, Chandra Shehkhar Reddy Potula wrote:
Hi Aline,
Versioning helps you iterate faster and prevents invalid requests from hitting updated endpoints. It also helps smooth transitions over any major API version as you can continue to offer old API versions for a period of time. Definitely supporting the old version of API period of time while offering new functionality with newer version always give benefits and extra time for end user to adjust to new one.
Well, we only maintain one branch which matches the latest release. So keep tracking of old version does not make sense for us. The patches are always applied on top of the current branch. To make clear, we don't maintain old versions.
I see lot of products in the market are adapting versioning (see below link) http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
I do understand the concern of maintaining the version of the API endpoints , below are some of the links from Openstack, which talks about it. http://developer.openstack.org/api-ref.html https://wiki.openstack.org/wiki/VersionDiscovery
Hope it make senses to you.
Regards Chandra
On 08/06/2015 12:04 AM, Aline Manera wrote:
Hi Chandra,
I don't see any benefit in adding the version in the URL. Instead of that, it scares me on how we will maintain it.
Once we move to wok and Kimchi as plugin, all the APIs will be automatically updated so everything will be in the same page.
Regards, Aline Manera
On 17/07/2015 09:47, Chandra Sr Potula wrote:
Hi Kimchi/Ginger Devel-Team,
Thank you for creating WOK branch to separate the kimchi plugin from the base frame work. It is a great idea.
Along with the separation of kimchi plugin looks like there is a transformation of REST API URIs as well. So thinking in those lines will it be good idea even to introduce version to the REST API URIs ?
Let me take one REST API URI to convey clear on what I am talking about.
To retrieve the host repository information, current URI is: "/plugins/kimchi/host/repositories".
*Recommendation*: New host repository URI can look like : *"**/plugins/kimchi/v<version>/host/repositories" , *so that it is easy to maintain REST API future enhancements at the same time do not brake some body who is using the existing URI.
Note* Adding version in the URI above is just an example and we could place the version in the URI best possible way.
Thanks and Regards, *Chandra Shekhar Reddy Potula* Staff System Software Engineer IBM Systems & Technology Group, Systems Software Development System z Firmware Development ------------------------------------------------------------------------ *Phone:* 91-080-4066-0786 | *Mobile:* 91-973-1122-221* E-mail:*_chandra.shekhar@in.ibm.com_ <mailto:chandra.shekhar@in.ibm.com> IBM
ORR, Manyatha MD3 1F B247 Bengaluru, Karnataka 560045 India
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (4)
-
Aline Manera -
Chandra Shehkhar Reddy Potula -
Chandra Sr Potula -
Harshal Patil