Hi Dejan,
IMO, the "most correct" way, respecting the clean architecture rule of
inward-pointing dependencies, is to have a bit of code at the
transport layer which introspects received errors and decides on an
appropriate status code. Here[0] you can see such a bit of code, used
in the error encoder[1]. Note the general response encoder[2] also
needs to check responses to see if they should be encoded as errors;
that's accomplished by type-asserting on a custom errorer
interface[3].
[0]
https://github.com/go-kit/kit/blob/a9ca672/examples/profilesvc/transport.go#L391
[1]
https://github.com/go-kit/kit/blob/a9ca672/examples/profilesvc/transport.go#L380
[2]
https://github.com/go-kit/kit/blob/a9ca672/examples/profilesvc/transport.go#L357-L362
[3]
https://github.com/go-kit/kit/blob/a9ca672/examples/profilesvc/transport.go#L344-L350
You could also choose to have your errors and response types implement
a StatusCoder interface, and use the values directly, in order to skip
the mapping function in the transport layer. I think this is not so
great, because it breaks the dependency rule, by embedding
HTTP-specific logic in your supposedly pure business domain. But some
people find it a useful compromise.
Regards,
Peter.
> --
> You received this message because you are subscribed to the Google Groups
> "Go kit" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
go-kit+un...@googlegroups.com.
> To post to this group, send email to
go-...@googlegroups.com.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/go-kit/d510bcc4-d271-42d3-bf06-446eb7a351d4%40googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.