API protocol was changed. Why no announcement?

edited July 2015 in Help
Around two weeks ago your API apparently was updated (some fields changed types from numbers to strings) which caused clients implementing your API to break. I think it unfortunate that this change was neither announced beforehand nor is it clearly documented until today.

Comments

  • Janek,

    Can you specify which fields had their types changed?
    Where did you find this information?
    Was this discovery a result of your current usage of the API?
    Did this cause your current calls to break?

    I apologize for the questions, but I am naturally skeptical of accusations that lack detail. More detail could help VULTR explain, and I am sure they are working on strengthening their update process, if this is in fact the case.

    Without detail, I purely see an accusation, without proof of its validity. Validation could also come from others having the same issue, so thank you for bringing this up!

    Take care!
  • @RoboticAdvisors, thanks for taking interest in this issue. Judging from your username you are not a Vultr employee, are you?

    >Can you specify which fields had their types changed?

    The pending_charges field (maybe others too) in the "server/list" endpoint response had previously been of type json float. 2 weeks ago it's type was changed to json string or at least started to erratically either be of type string or float.

    >Where did you find this information?

    Vultr API client for GO: https://github.com/JamesClonk/vultr/issues/5

    > Was this discovery a result of your current usage of the API?

    Indeed. I am working on supporting Vultr in Docker's management client, see https://github.com/docker/machine/pull/958.

    Did this cause your current calls to break?

    Yes.

    Just to be clear. This change in the API responses might not have been introduced deliberately. It might as well be a bug.
  • Hi Janek,

    Thanks for the feedback. The example we provide does indeed tell you to expect a string:

    https://www.vultr.com/api/#server_server_list

    It is possible that you were receiving a float for a particular account/combination but this is not the documented behavior so you may have hit a bug at that time. I've opened a ticket on your account and placed it in our development queue so if you are able to reproduce the inconsistent behavior and have additional details/feedback please provide it there.

  • edited July 2015
    Hi Mike, thanks for taking the time to look into this issue. As you suggested, at the time the API was implemented in the client, the response field did not have the documented type.

    A similar issue is still present in the "v1/startupscript/create" endpoint:

    Expected response (https://www.vultr.com/api/#startupscript_create)

    SCRIPTID: 5 (integer)

    Actual response:

    SCRIPTID: "5" (string)






  • edited July 2015
    PS: While we are having this conversation, let me share with you that the 1/sec API rate limit is a major obstacle for implementing Vultr's API in any form of cloud management/orchestration framework. It makes it impossible to do anything asynchronously and the end-user experience is horrible slow because of the need to enforce a 1 second sleep after each of several API queries that might be necessary to complete the action requested by the user.

    It's probably in your business interest that Vultr's cloud/server platform is supported by tools like docker-machine and others. Changing the rate limit mechanism to something more reasonable like an hourly or at least a per minute limit would be an important step towards this goal.
  • @janek - we've applied a patch to address the startupscript_create issue you pointed out.

    Thanks for the additional feedback regarding rate limiting.
  • @mike thanks for resolving this swiftly!
Sign In or Register to comment.