Json serialization breaking change

[StefanKert]

The current launcher version returns json in a different way than the old launcher. We basically return all properties with lower case start characters. IMO we should not change this behavior since it could result in a breaking change.

There are two options IMO

• Adapt the serializersettings
• Change serialization to newtonsoft json

[volllly]

Is this about the response of the rest endpoints (e.g. json/sign)?

[StefanKert]

Yep. I don't know if we are also having troubles between Queue+SCU but the REST endpoint is definitely affected by that.

[volllly]

AFAIK this is only wrong for the Echo endpoint because the Message field is in PascalCase and the launcher converted everything to camelCase 🤔 The ReceiptResponse fields are already camelCase so they should have been fine.

110 changes the behaviour to keep the casing as its defined in the datatypes 👌

[StefanKert]

Just as a quick example:

{
    "ftCashBoxID": "c0978914-4939-4604-ad24-62de3ad008ae",
    "ftQueueID": "46cea54f-ceb7-44b9-a041-35a2f7a413b4",
    "ftQueueItemID": "00a591ec-1d02-4ba6-a8b8-8588129d30c6",
    "ftQueueRow": 100,
    "cbTerminalID": "",
    "cbReceiptReference": "25902bd4-d9fb-4c9f-95be-08df46f35d4c",
    "ftCashBoxIdentification": "010000010",
    "ftReceiptIdentification": "ft26#",
    "ftReceiptMoment": "2023-10-15T08:35:58.7589096",
    "ftReceiptHeader": null,
    "ftChargeItems": null,
    "ftChargeLines": null,
    "ftPayItems": null,
    "ftPayLines": null,
    "ftSignatures": [
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 5283883447184523280,
            "caption": "<rt-serialnumber>",
            "data": "99IEC018305"
        },
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 5283883447184523281,
            "caption": "<rt-z-number>",
            "data": "0000"
        },
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 5283883447184523282,
            "caption": "<rt-doc-number>",
            "data": "0000"
        },
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 5283883447184523283,
            "caption": "<rt-doc-moment>",
            "data": "2023-10-15 10:36:01"
        },
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 5283883447184523284,
            "caption": "<rt-document-type>",
            "data": "REFUND"
        },
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 5283883447184523296,
            "caption": "<rt-reference-z-number>",
            "data": "0042"
        },
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 5283883447184523297,
            "caption": "<rt-reference-doc-number>",
            "data": "0015"
        },
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 5283883447184523298,
            "caption": "<rt-reference-doc-moment>",
            "data": "2023-10-15"
        },
        {
            "ftSignatureFormat": 1,
            "ftSignatureType": 0,
            "caption": "S A N D B O X",
            "data": "46cea54f-ceb7-44b9-a041-35a2f7a413b4"
        }
    ],
    "ftReceiptFooter": null,
    "ftState": 5283883447184523264,
    "ftStateData": null
}

The question is more or less if we should move back to Newtonsoft json for compatibility reasons.

[volllly]

In #110 we now should have full 1.3 backwards compatibility 👌