Konwencje i praktyki związane z typami danych w JSON

Cześć
Nie znam się na Javie i programowaniu na Android a piszę jakiś rozwiązania "z doskoku" więc proszę o informację mądrzejszych.

Wystawiam osobie piszącą aplikację dla Android proste API i zwracam JSONa np w takiej postaci:

{
    "Result": 1,
    "Info": "OK",
    "Counter": 1,
    "Data": [
        {
            "doc_Id": 44,
            "doc_SendDate": null,
            "doc_IssueDate": "2023-01-13T00:00:00",
            "doc_InvoiceValue": 237.4000,
            "doc_InvoiceNumber": "FV 40/1/01/2023"
        }
    ],
}

Wg mnie wszystko jest jasne i proste, jednak osoba od rozwiązania w Androidzie koniecznie chce, żeby:

1. wartości datetime muszą być przedstawione w bigint po przekonwertowaniu na Unix Timestamp
2. wartości decimal mają być przemnożone * 4 i przedstawione bez separatora
3. wartości null muszą być zastąpione wartościami "zerowymi" odpowiednimi dla danego typu (pusty string lub 0)

Czy faktycznie taka jest praktyka w przypadku współpracy z urządzeniami mobilnymi i oprogramowaniem w Java?
Czym mogą być spowodowane takie żądania? Czy jest to brak odpowienich typów danych po drugiej stronie czy też chęć ułatiwenia sobie pracy?

API będzie wykorzystywane także przez inne oprogramowanie i tam autor nie ma takich problemów.

Za mało info żeby powiedzieć coś więcej, ale najpewniej ma już gotowy model danych i ne chce mu się ręcznie parsować i konwertować danych z twojego json na jego dto.
Najpewniej też nie chce stosować ifologii i sprawdzać nule i je zamieniać na wartości (nie chce robić śmietnika w kodzie).
Z resztą to ty dopisujesz rozwiązanie do istniejącej już apki więc to ty masz się dostosować a nie na odwrót.

JSON jest dość ubogim standardem (stąd jego sukces), w szczególności ilość typów jest na palcach do policzenia

Skąd powstały takie założenia w twoim projekcie ... trzeba by zacząć od Adama i Ewy ... to co robisz, jest tylko drobnym dodatkiem do wielkiego juz zaprojektowanego / działającego systemu.

Co do "decimal" ... JSON wywodząc się od javaScriptu nie ma koncepcji typu stałoprzecinkowego, tylko double (każdy profesjonalista wie, co to oznacza). Czy nowoczesny JavaScrip ma prawdziwy nie będący emanacją doube'a integer, u mnie na wsi różnie mówią. Zawsze jestem przerażony, jak ktoś pieniadze liczy w JS albo PHP
Tutaj stawiający założenia mógł chcieć ratować dokładność (albo mu się tak wydawało)

Dodam tylko dodatkowe informacje :
Aplikacja dla Androida dopiero powstaje ( @hzmzp) i nie tylko ona będzie korzystać z tego API.
API właśnie jest łącznikiem do już istniejącego dużego systemu, do którego będą zapisywane dane i sposobu ich zapisu już nie mogę zmienić.

Nie chcę wchodzić na ścieżkę wojenną bo przecież nie o to chodzi, zależy mi bardziej o stosowane praktyki.

Oczywiście mogę null przekazywać jako 0 lub pusty ciąg znaków, datę jako timestamp, wartości kwotowe w integerach, ale dane będą również przekazywane do API i zapisywane w systemie, więc wtedy po mojej stronie będzie kwestia konwersji int na decimal (money w SQL), null dla zerowych dat itd.

Czyli jak rozumiem to nie kwestia techniczna tylko ustalenie, kto będzie te dane konwertował?

W takim razie powinniście iść na kompromis by apka nie pochłaniała za dużo zasobów na konwersje danych i żeby te dane były jak najbardziej spójne z tym co jest na obecnym systemie, tzn jak int jest nulem to powinien być nulem i w odpowiedni sposób przetworzony w apce androidowej.a nie że on chce mieć 0.

hzmzp napisał(a):

by apka nie pochłaniała za dużo zasobów

By nie pochałaniała dużo zasobów to protokól binarny (gRPC, Thrift i pdobny). Mikrooptymalziacje JSON nawet do tego nie startują.

hzmzp napisał(a):

W takim razie powinniście iść na kompromis by apka nie pochłaniała za dużo zasobów na konwersje danych i żeby te dane były jak najbardziej spójne z tym co jest na obecnym systemie, tzn jak int jest nulem to powinien być nulem i w odpowiedni sposób przetworzony w apce androidowej.a nie że on chce mieć 0.

No nie tutaj jest problem. Raczej ktoś wystawił API i nie chce, żeby było zmieniane. Konwersje i tak są „tak samo ciężkie”, bo konwertery JSON nie są królami prędkości i nie po to się je projektuje.

@AnetaZ problem jest czysto menadżerski, a nie techniczny. API jest, jak sama nazwa wskazuje, interfejsem, który oczekuje konkretnych zachowań od użytkowników. Nie wiem, z jakiej biblioteki do konwersji korzystasz, ale każda porządna biblioteka ma możliwość skonfigurowania zachowania dla null i wstawia czy to null, czy to domyślną wartość, czy to ignoruje takie pole. Jedyne co trzeba by z palucha napisać to konwerter do typu monetarnego, bo on musi wykonać „nietypową” konwersję mnożenie/dzielenie. Warto też zapytać, czy nie mają gotowej libki z potrzebnymi typami i konwerterami.

Można też wygenerować/napisać sobie odpowiednie typy z API i wtedy twój kod będzie działał na twoich typach, a komunikację robisz na typach zgodnych z API.

Dla mnie sprawa jest raczej oczywista. Api już istnieje i działa. Korzystają z niego różne aplikacje na zasadach takich, jak opisałeś. Nie wiem czemu oczekujesz, że ktoś będzie zmieniał te api i wszystko co z niego korzysta bo ci tak się akurat zachciało.

A że json jest ułomny no to jest. W końcu JavaScript Object Notation.

Czy wy czytaliście jego post, to ON ma naklepać to api, a jakiś typ wywiera nacisk żeby było tak jak wymyślił sobie to w apce androidowej.

Przede wszystkim wystaw temu API specyfikację choćby w OpenAPI bo to powinno być minimum przyzwoitości po stronie dostawcy API. To raz. Dwa - API zazwyczaj jest publiczne tzn. może mieć wielu odbiorców i każdy z nich może mieć różne wymagania. To z automatu stawia odbiorcę na gorszej pozycji do negocjacji jeśli o jego format/kształt.

Innymi słowy: nie daj się bo to zadaniem klienta jest dostosować się do formatu API a nie na odwrót (pomijając pewne wyjątki).

AnetaZ napisał(a):

1. wartości datetime muszą być przedstawione w bigint po przekonwertowaniu na Unix Timestamp
2. wartości decimal mają być przemnożone * 4 i przedstawione bez separatora
3. wartości null muszą być zastąpione wartościami "zerowymi" odpowiednimi dla danego typu (pusty string lub 0)

Pierwsze jest zasadne - timestamp jest dobrym rozwiązaniem, standardowym.
Drugie jest dziwnym sposobem żeby zwrócić informację - albo jest to wymóg Twojej konkretnej aplikacji, albo fanaberia tego kto Ci to zleca.
Trzecie jest bardzo dziwne, i nie wiem czy ma jakikolwiek sens.

Riddle napisał(a):

Pierwsze jest zasadne - timestamp jest dobrym rozwiązaniem, standardowym.

Ale dla jakiej epoki? No i co z przyszłością?

Czy faktycznie taka jest praktyka w przypadku współpracy z urządzeniami mobilnymi

Nie

i oprogramowaniem w Java?

A skąd wiesz że po drugiej stronie jest Java? Raczej Kotlin ale to może być cokolwiek, API powinien umieć skonsumować każdy sensowny język programowania, nie pisze się API pod konkretną platformę (chyba że masz upośledzonego frontendowca)

Czy jest to brak odpowienich typów danych po drugiej stronie czy też chęć ułatiwenia sobie pracy?

Raczej brakiem umiejętności i chęcią wykorzystania czegoś co ma już zrobione (wbijanie gwoździa gumową piłką).