Одинаковые имена полей с разным типом в JSON
1,00
р.
К примеру, есть модели:
public class Shipment { private int id private Destination destination private String status }
public class Destination { private int id private String company private String nameTo }
public class Order { private int id private String reference private List shipments }
Есть JSON ответ чтобы получить Order:
{ "id": 78, "reference": "FD456", "shipments": [ { "id": 86160, "destination": 172002, "status": "ready" } }
Есть JSON ответ чтобы получить Shipment:
{ "id": 86160, "destination": [ { "id": 172002, "company": "KLM inc", "name_to": "Alex" } "status": "ready" }
Как видно в первом JSON поле destination хранит просто id, а во втором JSON приходит уже сам объект Destination. Как я понимаю это сделано в целях оптимизации, но вопрос состоит в том, как хранить такое различие типов в моделях?
Ответ
Такое получилось из-за БД на стороне API
С точки зрения API там два разных типа данных: сама модель и ссылка на модель. В самом общем смысле. "Голый id" это ссылка, по которой API может однозначно найти нужную запись. Скорее всего, это внешний ключ в какой-то SQL-базе.
Если у вас, потребителя API, есть своя БД, то в ней это можно представить, как поле, хранящее ..._api_id (где ссылка) и api_id (где значение). Как внешний и первичный ключ (соотв-но), но поскольку в базе "снаружи", соответствующие значения есть не всегда. Если пришла ссылка, то сохранить только в это поле, если значение, то сделать строчку в другой таблице и заполнить это поле.
А если базы нет, можно завести singleton-мапы id => объект и... дальше варианты.
Если вы уверены, что эти объекты меняются редко, эти мапы можно использовать, как кэш. Например, получили вы id, и оказалось, что в мапе эта запись уже есть (ранее у API спрашивалась), можно её сразу и взять. А если считаете, что они меняются часто, то вам придётся делать ещё один запрос, чтобы точно получить самую свежую версию объекта. Можно совместить два подхода, и обновлять объект только если запрос был достаточно давно. Да-да, пресловутый "cache invalidation".
Так или иначе, в объекте у вас будет только число — ключ для мапа. Если в мапе такого значения нет, его надо достать с API и записать в мап. Вам стоит поискать в этом API место, которое вам этот объект выдаст целиком.
В приведённых JSON-ответах разработчики, вероятно, решили, что данные смежных объектов нужны часто и решили их вложить по значению, а не по ссылке.
public class Shipment { private int id private Destination destination private String status }
public class Destination { private int id private String company private String nameTo }
public class Order { private int id private String reference private List shipments }
Есть JSON ответ чтобы получить Order:
{ "id": 78, "reference": "FD456", "shipments": [ { "id": 86160, "destination": 172002, "status": "ready" } }
Есть JSON ответ чтобы получить Shipment:
{ "id": 86160, "destination": [ { "id": 172002, "company": "KLM inc", "name_to": "Alex" } "status": "ready" }
Как видно в первом JSON поле destination хранит просто id, а во втором JSON приходит уже сам объект Destination. Как я понимаю это сделано в целях оптимизации, но вопрос состоит в том, как хранить такое различие типов в моделях?
Ответ
Такое получилось из-за БД на стороне API
С точки зрения API там два разных типа данных: сама модель и ссылка на модель. В самом общем смысле. "Голый id" это ссылка, по которой API может однозначно найти нужную запись. Скорее всего, это внешний ключ в какой-то SQL-базе.
Если у вас, потребителя API, есть своя БД, то в ней это можно представить, как поле, хранящее ..._api_id (где ссылка) и api_id (где значение). Как внешний и первичный ключ (соотв-но), но поскольку в базе "снаружи", соответствующие значения есть не всегда. Если пришла ссылка, то сохранить только в это поле, если значение, то сделать строчку в другой таблице и заполнить это поле.
А если базы нет, можно завести singleton-мапы id => объект и... дальше варианты.
Если вы уверены, что эти объекты меняются редко, эти мапы можно использовать, как кэш. Например, получили вы id, и оказалось, что в мапе эта запись уже есть (ранее у API спрашивалась), можно её сразу и взять. А если считаете, что они меняются часто, то вам придётся делать ещё один запрос, чтобы точно получить самую свежую версию объекта. Можно совместить два подхода, и обновлять объект только если запрос был достаточно давно. Да-да, пресловутый "cache invalidation".
Так или иначе, в объекте у вас будет только число — ключ для мапа. Если в мапе такого значения нет, его надо достать с API и записать в мап. Вам стоит поискать в этом API место, которое вам этот объект выдаст целиком.
В приведённых JSON-ответах разработчики, вероятно, решили, что данные смежных объектов нужны часто и решили их вложить по значению, а не по ссылке.
