Closed spheromak closed 9 years ago
@marpaia I am interested in your thoughts on this. I would like to reduce/normalize the middle operations in the API. This is one of the first steps to that, but i understand if you don't like it cause it is breaking the existing stuff.
Hmn, this is interesting. I think that this project is young enough where we shouldn't worry about breaking TOO much of the public API, especially non-direct components such as Get. I only made Get public so that people could use it to hit API endpoints I hadn't implemented, but since I've never seen a PR for anything like that, I don't think it happens much. My vote is to go for it.
We should also consider making turning Get
into get
. I wonder if anyone actually uses it. I'd prefer for people to use get
only to hit API endpoints, which should all be in the library. Thoughts?
With that being said, we should start following semantic versioning soon so users can be aware of changes that break the API.
re: privatizing the base methods. I think these should be exported. This allows folks to play on the server however they see fit, and not be tied to our structs. This is like the raw methods in Chef::Rest ruby lib for chef-client.
The simplest usage of this lib should be create a connection and run some method. IMO, and I don't want to take that power away.
I'll go ahead and update the other methods too use the same signature before i merge this so we only break that part of the API one time.
@spheromak is this PR dead?
I'm using the code to issue 'raw' Get/Put/Post requests, please keep these public. Having full support for the full chef-server api is the way to go naturally, but the lower-level stuff is needed when you know what you are doing, modding an acl would be an obvious example.
@sspans @marpaia this PR is what led me to start the go-chef/chef impl I am not actively working on this line of thought within chef-golang. If we can do a chef-golang 2.0 where we totally rework it then maybe it makes sense, but thats why I started working on a from scratch lib instead.
chef.GetWithParams can also be serviced by chef.Get This changes the internal calls to Get and GetWithParams to support this.
This would break anything that might be calling Get or GetWithParams directly. I think it is wise to reduce this now.