Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

xis's avatar
Level 1

JavaScript (Vue) & Laravel API naming convention conflict

Hi there,

I am a bit confused about what the best way is to handle the naming convention different between Laravel API and my SPA (Vuejs). My Laravel API uses the default Laravel naming convention and returns data using the underscore case (f.e. post_id, user_id, ...) while my SPA uses the camelCase naming convention. Because of the naming different I get this ugly code (see example below) where the 'v-if' is using underscore variables returned from my Laravel API and the 'v-model' is using my camelCase variables defined in Vue.

<default-input
     v-if="authentication.require_first_name"
     v-model="data.firstName"
     label="First name"
     required
/>

Is it "acceptable" to have these different naming conventions in one codebase? Should I manually transform the underscore case naming from my API to camelCase naming in my Vuejs application on each API request? The same for sending data back to my API, should I transform my Vuejs camelCase data (f.e. firstName) to the underscore case naming convention (f.e. first_name) before sending it back to my API? ...?

Thanks in advance.

0 likes
4 replies
automica's avatar

@xis json api's should respond with camelCase.

If you use API Resources you can do this on a model per model basis

https://laravel.com/docs/8.x/eloquent-resources

eg..

/**
 * Transform the resource into an array.
 *
 * @param  \Illuminate\Http\Request  $request
 * @return array
 */
public function toArray($request)
{
    return [
        'id' => $this->id,
        'firstName' => $this->first_name,
        'lastName' => $this->last_name,
    ];
}

to convert to snake_case on the way back in, you can do:

use Illuminate\Support\Str;

$converted = Str::snake('fooBar');

although, I would be explicit and just manually convert

eg

$model = Foo::create(
    [
        'first_name' => $request->firstName,
        'last_name' => $request->lastName
    ]
)
1 like
xis's avatar
Level 1

Thanks for the reply @automica

Using resources to convert underscore to camelCase is actually what I am already doing but thought it was bad practice as most APIs we use (f.e. Stripe, PayPal, Youtube, ...) all use snake_case to return data from their APIs. I Found a Google JSON Style Guide that indeed suggest using camelCase. I will continue using my resources approach for now. I am going to wait for others to share their opinion on this topic before I make a decision. Thanks again.

martinbean's avatar
Level 80

json api's should respond with camelCase.

Should they…?

@xis You’re going to get casing conflicts somewhere down the line. Don’t let your front-end dictate your naming conventions server-side. Because if you accommodate one client, then you’ll find another that wants something different, and then you end up trying to appease multiple masters.

I personally use snake_case because that’s what I use for request input as well. So it makes sense to output the same case in responses as you ask for in requests. It’s a bit weird to use snake_case input names, but then return those same responses with camelCase keys.

So thinking along those lines, treat input names as exactly that: input names and not JavaScript variables. I have a Form object that I use to encapsulate data that gets sent to an external URL that’s based on Spark’s SparkForm object:

export default {
    data() {
        return {
            form: new Form({
                name: null,
                email: null,
                phone_number: null,
            }),
            someDataKey: null,
            someOtherDataKey: null,
        };
    },
};

I’ll use snake_case for inputs that require them, and camelCase anywhere else. And it’s fine to do so. No one will come and tell you off.

Just remember, if this were a third-party API you wouldn’t have the luxury of being able to pick case. If the API told you they accept snake_case, then that’s what you’d have to send, regardless of what you wanted to use in your JavaScript.

2 likes
xis's avatar
Level 1

You are correct, my front-end should not dictate the naming convention of my server-side as I will expose a part of it to the public so customers can use it as they like. Our old legacy (non-laravel) apis use snake_case for input & output so it will be weird to suddenly start using camelCase. Thanks for sharing your "Form" approach. I think I will create some function for my vuex store that converts snake_case to CamelCase and vice versa for incoming and outgoing data so I can keep using camelCase in my components.

Please or to participate in this conversation.