Last Updated: 2024-11-23

Code in different languages has different naming conventions. This is an unfortunate reality. For example, Ruby uses snake_case and its API endpoint code will look most natural when working with this style. By contrast JavaScript uses camelCase.

Example Issue:

In JavaScript I had this:

submitAsForm(createSubscriptionPath, {
  // Pay attention to the `paymentMethod` bit
  paymentMethod: setupIntent.paymentMethod
})

And in PHP I had this code to receive this request:

<? php
public function create(Request $request){
  $user = Auth::user();
  $planName = 'premium';
  // Pay attention to the `payment_method` bit
  $paymentMethod = $request->input('payment_method');

This failed, saying that input('payment_method') was null, which of course it was since my JavaScript was sending over input('paymentMethod') (different naming convention).

Solutions

In general these bugs happen a lot at the seams between languages.

If all programmers co-ordinated, the wisest way to deal with things would be to use the superior version (IMO the more readable snake_case) in every language.

But right now the JavaScript ecosystem is in camelCase so snake_case would be jarring. Here you might continue having your keys in snake_case, but limit their existence to within JSON. This way it's clear that it is "foreign" input that does not conform to the usual naming conventions of JavaScript.

Lastly, if JSON is not an option, you could transparently transform the keys into camelCase on receipt from API endpoints and do the inverse transformation for incoming JavaScript data in the Ruby (etc.) backend.