On 04/27/2010 10:47 AM, Jesus Rodriguez wrote:
On Tue, Apr 27, 2010 at 10:36:11AM -0400, Adrian Likins wrote:
> On 04/27/2010 10:04 AM, Jesus Rodriguez wrote:
>
>> On Tue, Apr 27, 2010 at 09:21:27AM -0400, Bryan Kearney wrote:
>>
>>
>>> One of the backlog items talks about API versioning:
>>>
>>> (E2) As an application integrator, I would like to define what version
>>> of the API I support in order to be protected from API changes.
>>>
>>> The currenting thinking I am hearing is that you could use the media
>>> type for this, but it would be easier to just use the URL Path
>>>
>>> /candlepin/some/resource
>>> candlepin/v2/some/resource
>>>
>>> where no v implies v1.
>>>
>>> If folks are comfortable with that, it would mean no work until we do
>>> v2. I would move this off the backlog unless there were concerns.
>>>
>>>
>> I like the URL but without the v
>>
>> /candlepin/2.0/some/resource
>>
>>
> +1
>
> But... the question is what makes something a new version of the api? Do
> we go full major.minor.micro and do the:
>
> micro: bug fixes, nothing added or removed, no args or return values changed
> minor: new stuff added, optional args added, nothing removed
> major: might as well start over buckaroo!
>
the 3 digit version is useful,
smugmug.com does this. And the above
definitions make sense.
jesus
I'm hoping that by the time we actually revisit this, we will come up
with something better. The versioning scheme seems like it is in the
wrong place.
It seems to me that the Version number is far more an element of the
resource than an item in the URL path. Thus, I can see the argument for
putting a version string into a document, and perhaps even requiring one
for certain posts where the infomration is not complete unambiguous.
But injecting it into the URL just sits wrong. I think this idea
needs to lay fallow for a while, and only get implemented if we decide
we really need it.