When you're representing error cases as a sealed class, what's your preferred solution to send them to the client? I don't want to duplicate the entire hierarchy for serialization.

Why don't you just serialize the sealed class and it's classes?

They're in the domain layer, not the HTTP layer.

But the HTTP layer has access to them, no?

Internally yes, but it's not allowed to send them via the network.

I don't want to duplicate the entire hierarchy for serialization.

sounds like you need to send all of their contents anyways...?

If I serialize the domain classes, then they are part of the HTTP API. I don't want to worry about breaking the HTTP API when I edit the domain layer.

Do you have a standard way of representing errors that you need to return to apps/etc.. (like

data class Error(val code: Int, val name: String, message: String)

)? (How would you manage your contract with them otherwise?... I mean w/o copying over the while hierarchy... since it's not "just for serialization", but acting as an actual contract...) If so, it's just a matter of adding those fields to the base of the sealed class as an interface, and then just serializing that...

I think I'd add something like this in the HTTP layer, I wouldn't like to add HTTP status codes in the domain

fun BusinessError.toHttpBody() = when(this) {
  is UserNotFound -> Error(404, "USER_NOT_FOUND", "User $id was not found")
  is OperationNotAllowed -> Error(403, "SOMETHING", "...")
}

Yeah, you're right... that's better for http status codes, but for an error code that's more linked to the business logic, it could still be there, and then transformed to an http status code on the http layer Depending on how complex your structure is (and if you're using KotlinX Serialization), you could always convert the domain errors to JsonElement on the http layer and maybe even use https://github.com/nomisRev/kotlinx-serialization-jsonpath to map results. (if there's some kind of common structure in them... otherwise, it might just be easier to do what Emil proposed...)

@Emil Kantis I'm doing something similar, the problem is converting them back to domain errors client-side.

Is it a service-to-service call? Frontend to backend? In general I would use the

Error::code

and have a separate set of domain errors on the other side

Backend–frontend

Why are you not allowed the share the domain errors via network then, if they're shared to begin with? 😕

I'm allowed to share the domain error, not the specific classes they are used to implement. What if someone renames a field in the domain? It shouldn't be a breaking HTTP change when the HTTP layer wasn't even modified.

Is your frontend Kotlin-based? 😄

Yes, but a third-party is also consuming the HTTP API.

Or having a custom serializer that does the conversion? Then it would break if something was changed in the domain. If anyways you'd have to map from the domain to the copied http layer classes, might as well just to it straight to json...

I guess the HTTP layer could register serializers for the domain classes and maintain them.

How would you document with DTOs?

DTOs are regular classes, they can have Kdoc

But that's not what you would release as http api docs?

Indeed. I don't have proper API docs currently.

All that dokka really gives you (apart from the text you wrote there) are the serialized properties and the hierarchy... I'd maybe consider some better alternative... otherwise, you could avoid a bunch of complexities there that an api user would never really need to know about.

Ktor doesn't, sadly.

That's for hosting a file you wrote yourself.

That's a custom API over Ktor that is configured via annotations and doesn't use the regular Ktor methods

It seems like he forked that one: https://medium.com/nerd-for-tech/openapi-generation-with-ktor-d57879ec5ab0

I think OpenAPI support is on the Ktor roadmap

I know how to do a Google search, you don't have to copy-paste all results you see.

Oh, okay.. unfortunate 😞

A little late to add this @CLOVIS, but maybe this might be good for you (if you'd want another dependency to your project...). It's more explicit/dsl-like than a regular serializer, and breaks if you domain does: https://github.com/uberto/kondor-json

That's essentially the same as KotlinX.Serialization but without the compiler generator, isn't it?

No it's not the same as KotlinX Serialization... because you still need to convert from domain objects to http layer objects if you use the compiler generator... here, you explicitly define the mapping to the Json...