[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: How to know what's supported in REST service 1.1?



----- Original Message -----
> 
> On 09/05/2012 06:53 PM, Clayton Coleman wrote:
> 
> 
> ----- Original Message ----- When we fetch the api doc we'd specify
> no version, then check the list of supported versions. If the
> command we have needs a specific version and the server supports it,
> we'd refetch the api doc with the required version (or we'd do the
> converse where we'd ask for API version X and then if it fails, try
> without the specific version. Either way). api returns the list of
> supported versions and we'd intersect that with our "known" versions
> to give a warning.
> ok got it, pretty much enlightning, thanks a lot!
> So basically - if I get it right, you'll have a common lib for all
> versions and handle versions by branching logic. You'll track the
> required API for each operation and branch internally. I guess that
> this is simpler for a command line driven tool than it is for a lib
> that holds a state. We actually offer objects to users, that reflect
> the openshift resources (applications, domains, etc). I guess that
> we'll have to maintain distinct objects for each major version
> (while inheriting common logic/states). Please correct me if you
> think that I'm wrong.. ;)
> 

The shape of the API objects is likely to be coerced, with backwards compatible gaps being present.  I don't have a good answer yet because we haven't tried it substantially (and to be honest, for the CLI I expect almost no changes over the next year except for new function).  The API we'd call for most important operations is likely to be stable (create, delete, update).  Support for multiple domains is likely to be the first point of serious complexity.

> 
> 
> 
> 
> I should note that rhc and the console now both send their version
> number as part of the user agent - see
> https://github.com/openshift/rhc/blob/master/lib/rhc/helpers.rb#L48
> .  If the OpenShift Java API is not doing that today I highly
> recommend us getting that changed as soon as possible. good point,
> thanks for reminding. But we actually do, since quite a long time.
> We send a custom user-agent that also includes the client lib
> version:
> https://github.com/openshift/openshift-java-client/blob/master/src/main/java/com/openshift/internal/client/RestServiceProperties.java#L60
> 
> 
> I think we plan on avoiding semantic breaks for as long as possible,
> by tolerating multiple different properties.  Removal of properties
> or a change in their meaning should always be a "major" version
> change and as a consequence we will try to coordinate those removals
> with all teams.
> Yes, we'd highly appreciate being informed about breaking changes
> since this is pretty crucial for us.
> 
> 
> Cheers
> André
> 


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]