-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sttp model does not describe how to match different responses to different models #5
Comments
@chameleon82 This is currently done in sttp-client: For generating servers and documentation, this is also covered by sttp-tapir: https://tapir-scala.readthedocs.io/en/latest/endpoint/basics.html. There, the endpoint description contains information on how to map responses to errors and success values. Would you somehow see a new abstraction in sttp-model? What kind of use-cases would it cover? |
@adamw my concern about request model is to be more self-described. sttp-client cover only success/unsuccess case, but, for example, i can specify endpoint with the next expected mappings:
Of course, i can parse it to necessary models with additional callback on Left. But would it better if I can describe it with a model? |
I think this is doable right now with sttp-client. For example, you can create the following response specification:
is this something as you had in mind? |
@adamw Yes, exact that |
@chameleon82 great, so - is what is currently available in sttp-client enough for your needs, or do you have a use-case that's not covered? Maybe you have a good idea on how some of this could be moved to sttp-model :) |
@adamw I tried next example
It wont compile due expecting But what I see here is that For example above it could be transformed into something like this:
|
@chameleon82 ah yes, that' beacuse |
And yes, you can abstract over the serialization specifics. In the end, you need to provide a |
@adamw Thanks, code fixed with |
this compiles just fine:
direct modification of your example :) |
@adamw I stuck with same solution :)
I tried next approach:
but it wont compile also due implicit decoders not provided in trait But it works fine if I change it to specific implementation
Seems issue related to client, not to model. Should i open new issue in client for that? Back to topic i see tapir use |
Ah you want to abstract json generation ... the problem is that json codec derivation with circe is a compile-time mechanism, to in order to perform the derivation, you need to know (at compile-time) the concrete class for which to derive the codec. So at the point where you call The tapir codecs might end up in a separate project (maybe here as you write), however they are more powerful than what's needed in the client: the additionally capture validation, schema, and are bi-directional. On the other hand, for the client it's enough to decode (for responses) and encode (for requests). |
Following generic response as type I think generally it is good to return Success(model) for successful (2xx) result and Error/Exception for any other cases. And for expected error cases like not found i can have general ApiError which can be useful to separate business logic errors from transport/serialization errors. So right now i can return ApiError[ApiResponse] as exception explicitly throwing it:
but ii seems is not to be correct in general as my result type is Would it better to have an ApiError as part of the ResponseError?
Or my expectations is not really correct and i should operate with more generic ps: it could be also useful if HttpError will have status like: |
I think it depends on what your target model is. You can either have typed errors - where at least some of the errors are represented as a case class - or untyped errors, just using If the latter, then the generic response type should be If you do have typed errors, then you would probably need a custom hierarchy, covering three cases:
I'd represent transport errors as exceptions (or failed effects), as these are distinct from the errors described above: in that case, there's no response received at all. There's no need for |
This should be fixed in sttp 3.0, by supporting typed errors in |
Usually in REST applications one endpoint provide multiple models for response, generally at least one model for successful response and one for error.
It could be very useful to able to describe every expected answer and match it to client model.
One of the cases to use is able to create autogenerated clients. Here is example how model describe answers in OpenApi
https://github.com/OpenAPITools/openapi-generator/blob/master/samples/client/petstore/scala-akka/src/main/scala/org/openapitools/client/api/PetApi.scala#L38
The text was updated successfully, but these errors were encountered: