camelCase and snake_case are mixed in the admin API #381
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#381
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In the admin API, camel case and snake case are mixed, for example on
/status
:garageVersion
is in camelcaseis_up
is in snake caseI would say that snake case is more idiomatic for JSON.
Could we convert everything to snake_case? As it is a breaking change, can we do this at the same time we handle other tickets, like #378?
Also the doc is incorrect as it says
garage_version
and notgarageVersion
.https://garagehq.deuxfleurs.fr/documentation/reference-manual/admin-api/
Normally everything is camelCase. Anything that is not is a bug and should be fixed. Here is an example of how to make a struct camelCase when it is serialized:
Do we really want to rename everything in camel case?
Serde by default generate snake case on JSON and snake case is a standard among JSON REST API. For example, the Twitter API uses snake case JSON: https://developer.twitter.com/en/docs/twitter-api/v1/data-dictionary/overview
What are the benefit of camel case in our context?
In the other way, forgetting to put a "rename tag" is very easy: do we really want to add this complexity in the development? I am sure that it will be forgotten for some other structures in the future.
I don't mind changing to snake_case in theory. In practice it might break some user's workflows?
I think we should keep the admin API in its current state for garage v0.8.x, collecting as much feedback as possible, and release a
v1
fixing all the issues we referenced for v0.9.0 :-)Fixed by multiple commits (
bf19a44fd9
,35c108b85d
) in branchnext
, which will be merged for Garage v0.9The choice was made to stick to camelCase everywhere (which is fairly common in many json protocols, e.g. JSON-LD/ActivityPub)