Моделирование объектов API с учетом внутренней реализации

Question

Если вы создаете службу REST, которая обслуживает Banana объекты, вероятно, существуют две разные концептуальные модели этих бананов.

1. Что используется в REST API, который вы обслуживаете для публики
2. Что используется внутри приложения, с возможными полями БД, которые не предоставляются извне

Можно отразить эту реальность в коде, имея два класса с преобразованиями между ними:

class Banana {
  private String color;
}

class InternalBanana {
  private int id;
  private String color;
  private ZonedDateTime createdAt;

  public toBanana() {
    return new Banana(color);
  }
}

Плюсы:

• Маршаллинг Джсону через jackson прост
• Banana можно использовать во время тест-драйва кода API

Минусы:

• Дублирование кода
• Преобразователи внутренних объектов необходимо обновлять каждый раз, когда обновляется API

Так что, если мы объединим два класса:

class Banana {
  private int id;
  private String color;
  private ZonedDateTime createdAt;

  public String toApiJson() { ... }
}

Плюсы:

• Без дублирования
• Кажется более устойчивым к изменениям в публичном API

Минусы:

• Нет модели объектов REST API
• Для маршалинга в Json требуется специальный код
• Внутренние поля часто будут null

Какой подход, вероятно, будет наиболее эффективным в течение срока службы данной услуги?