Scala идиома для частичных моделей?

Question

Я пишу HTTP REST API, и я хочу строго типизированных классов модели в Scala, например. если у меня есть модель автомобиля Car, я хочу создать следующий RESTful /car API:

1) Для POST с (создать новый автомобиль):

case class Car(manufacturer: String, 
       name: String, 
       year: Int) 

2) Для PUT сек (изменить существующий автомобиль) и GET s, я хочу тег вдоль id тоже:

case class Car(id: Long, 
       manufacturer: String, 
       name: String, 
       year: Int) 

3) Для PATCH эсов (частичное редактирование существующего автомобиля), я хочу этот частичный объект:

case class Car(id: Long, 
       manufacturer: Option[String], 
       name: Option[String], 
       year: Option[Int]) 

Но сохранение трех моделей по существу одного и того же элемента является избыточным и подверженным ошибкам (например, если я отредактирую одну модель, я должен запомнить другие модели).

Существует ли типичный способ поддерживать все 3 модели? Я в порядке с ответами, которые также используют макросы.

мне удалось объединить первые два из них следующим образом

trait Id { 
    val id: Long 
} 

type PersistedCar = Car with Id 

Answer 1

На самом деле мне удалось решить эту проблему, используя маленькую библиотеку, которую я написал: https://github.com/pathikrit/metarest

Использование выше библиотеки, это становится просто:

import com.github.pathikrit.MetaRest._ 

@MetaRest case class Car(
    @get @put id: Long, 
    @get @post @put @patch manufacturer: String, 
    @get @post @put @patch name: String, 
    @get @post @put @patch year: Int) 
) 

Answer 2

Я бы с чем-то вроде этого

trait Update[T] { 
    def patch(obj: T): T 
    } 

    case class Car(manufacturer: String, name: String, year: Int) 

    case class CarUpdate(manufacturer: Option[String], 
         name: Option[String], 
         year: Option[Int]) extends Update[Car] { 
    override def patch(car: Car): Car = Car(
     manufacturer.getOrElse(car.manufacturer), 
     name.getOrElse(car.name), 
     year.getOrElse(car.year) 
    ) 
    } 


    sealed trait Request 
    case class Post[T](obj: T) extends Request 
    case class Put[T](id: Long, obj: T) extends Request 
    case class Patch[T, U <: Update[T]](patch: U) extends Request 

С Post & Положите все просто. С Patch немного сложнее. Я уверен, что класс CarUpdate можно заменить автоматическим с помощью макросов.

Если вы обновите модель автомобиля, вы наверняка не забудете о патче, потому что она не сработает во время компиляции. Однако эти две модели выглядят слишком «copy-paste-like».

Answer 3

Хотя я согласен с комментарием Павла (да, у вас было бы много дублированных полей, но это потому, что вы развязываете внешнее представление полей во внутреннее представление полей, что хорошо в если вы хотите изменить свое внутреннее представление без изменения API), возможный способ добиться того, что вы хотите, может быть (что, если я правильно понял, это иметь единое представление):

case class CarAllRepresentationsInOne(
    id: Option[Long] = None, 
    manufacturer: Option[String] = None, 
    name: Option[String] = None, 
    year: Option[Int] = None) 

Поскольку у вас есть значения по умолчанию для всех, заданных как «Нет», вы можете создать экземпляр этого CClass со всех маршрутов, при этом единственным недостатком является использование именованных параметров во время создания экземпляра и проверка на отсутствие во всех использование полей.

Но я бы настоятельно рекомендовал иметь разные типы для вашего внутреннего представления и для каждого возможного внешнего ресурса запроса: это может показаться дублированием кода в начале, но способ моделирования автомобилей в вашем мире должен быть отделен ресурсами используемый внешним миром, чтобы отделить их и позволить вам изменять внутреннее представление, не изменяя контракт api с внешним, когда возникают новые потребности.

Answer 4

Вы можете представить свои модели как Shapeless records, тогда id - это просто еще одно поле на передней панели, а отображение в/из параметров можно выполнить в общих чертах, используя обычные методы программирования типа Shapeless.Также должно быть возможно обобщить/десериализовать такие вещи на JSON (я делал это в прошлом, но соответствующий код принадлежит предыдущему работодателю). Но вы определенно будете толкать границы и выполнять сложное программирование на уровне уровня; Я не думаю, что до сих пор существуют зрелые библиотечные решения с таким подходом.