catwatch
catwatch copied to clipboard
Follow REST API guidelines: snake_case JSON properties
The Catwatch API should follow the Zalando REST API guidelines, including:
- Snake-case JSON properties (i.e. use "organization_name" instead of "organizationName")
Currently the "/projects" endpoints (to name one) returns camelCase JSON properties.
Hi @hjacobs,
In my personal and humble opinion, I think this is not an issue, why? Because this is an open source project so we shouldn't force to Zalando's guide lines. Maybe an idea could be: making the format configurable.
In addition, a personal thought:
- In what programming language most of the web client applications are written today? I think we can answer Javascript.
- What JSON stay for? JavaScript Object Notation
- Which is the de-facto javascript naming convention? camelCase (native javascript use camelCase and also every popular javascript library too)
So.... well ... I was really surprised when discovered that Zalando recommends snake-case for JSON responses.
It's about consistency, and your personal opinion aside: the swagger.yaml already has partly snake_case (https://github.com/zalando/catwatch/blob/master/catwatch-api/catwatch_rest_api.yaml) ;-)
Ok... I agree about consistency. :+1:
@rbarilani @hjacobs Do we need to resolve this further in any regard?
It's about following our own RESTful API guidelines, see http://zalando.github.io/restful-api-guidelines/
@hjacobs Yep, but there's been disagreement here on whether we should follow them or not. My suggestion is that both for's and against's (who want to have a stake in the matter) briefly describe the reasons why we should adopt said approach, and pitch their ideas to the CW dev team to decide.
From Zalando point of view it'd be nice if our APIs (either business related or open source projects) are looking similar.
@LauriZalando as I already said, I agree to go with snake_case for being consistent with our guide lines. Just point out that it could be a breaking change for clients as zalando.github.io.
@hjacobs @fmueller @rbarilani Seems we've achieved compromise here, no? Follow our own guidelines, and add a line in the README as per Ruben's point. If this seems right to you, just leave a thumbs-up and we can close (I wouldn't want to drag this out further, as we should be following our own guidelines in any case)