Difference between using and not using get; set; in data passed from backend

Question

What is the difference between using and not using get; set; in data passed from backend?

I saw examples like this in Apex:

using get; set;

public with sharing class MyBackendController {
    public class WrapperDataClass {
         @AuraEnabled
         List<Contact> contactsList {get; set;}
    }

    @AuraEnabled
    public static WrapperDataClass doesnotMatter() {
        WrapperDataClass res = new WrapperDataClass();
        //does not matter how res is filled
        return res;
    }
}

not using get; set;

public with sharing class MyBackendController {
    public class WrapperDataClass {
         @AuraEnabled
         List<Contact> contactsList;
    }

    @AuraEnabled
    public static WrapperDataClass doesnotMatter() {
        WrapperDataClass res = new WrapperDataClass();
        //does not matter how res is filled
        return res;
    }
}

Previously I thought that using get; set; is obligatory. But I forgot to include it a few times in my code and still everything worked the same way.

So, I am going not to use get; set; at all. Will I be fine or am I missing something?

Thank you.

Answer 1

On the one using the get; set; you can control if get; or set; is private or not by using private get; and private set; ... Mostly you use properties for Visualforce pages.

So Apex properties are similar to variables but there are additional things you can do with them.

There are many particular things that are part of the Apex Properties that are not part of variables.

Answer 2

The { get; set; } code is only obligatory for Visualforce pages that bind to those variables. In all all other cases, { get; set; } is superfluous, and not required. This includes using those variables in JSON serialization/deserialization, objects used in Lightning, etc. However, @AuraEnabled is required in order to be visible to Lightning. There is no difference between specifying { get; set; } or not; it has the exact same behavior either way.