Closed stoically closed 2 years ago
This PR doesn't make explain at all why this change is being made. Can you please explain?
Because otherwise I can't serialize/deserialize the response. Which I thought I need, but actually is no longer needed if I use the ruma/sdk send methods, right.
Still, if I wanted to do de/serialization - like, storing the account as JSON somewhere, I would need the refactor again. Which would be solved by deriving on the response
.
So, feel free to close if you prefer.
If we were to allow request / response (de)serialization, it should be done consistently, not like this. It's something that's been discussed in Ruma before, but I'm not a fan of. I couldn't find the issue right now, but it seems like it's not so important right now anyways.
Yeah, makes sense. If you happen to stumble over the issue, I'd be interested in the link.
I checked again, here it is: https://github.com/ruma/ruma/issues/10
It was closed because nobody showed interest in it and the implementation bits from the issue description went out of date. I think I would also push back harder against such a feature now should it be proposed again, since it would make it easier for people to do the wrong thing in serializing all request fields as body fields.
Just a realization as consumer: This would not have been needed with serialize/deserialize directly on the ruma_api! response.