Access to the raw json on a per (sub)model basis would be convenient for score statistics type things

[Syriiin]

https://tybug.github.io/ossapi/serializing-models.html#serializing-models

Please open an issue if this approach is not sufficient for your use case.

There are some cases where access to the raw json returned by the API would be preferrable, for example: score mods and statistics.

For example, with statistics, the API intentionally omits 0 fields, which is convenient when storing the json for millions of scores.
It would be convenient if this was just exposed by ossapi, so I could avoid recreating that json format.

Not a big deal, but a tad inconvenient.

[Liam-DeVoe]

The main reason I don't just store the json as an attribute on the model is that it could take a decent amount of memory, especially for nested models. We could:

• (1) add store_json: bool = False to each request method. I think this is an ok option, but it does add redundancy to the interface.
• (2) add store_json: bool = False to Ossapi. This doesn't let you opt out/in for specific methods. I think I'm okay with that because you can create two Ossapi instances, one which stores json and one which doesn't. But it's not the cleanest either.

Either way I think this will yield a new model._json attribute with the raw json response.

[Syriiin]

Either (or both) options seem reasonable to me.
If enabling this is part of the ossapi public interface though (store_json: bool = False), using an internal member (model._json) to expose that data seems a bit backwards.

I'd suggest perhaps either:

1. add a public method model.raw_json() that would return the value of model._json (or throw if store_json=False)
2. have serialize_model() return model._json if it is set

I prefer the first option, because with option 2, store_json would impact the functionality of serialize_model() which could be unexpected from the user perspective.

[Liam-DeVoe]

Hmm, the intention of the underscore is to avoid clashes with potential api attributes. An alternative is something like .ossapi_json, which is unlikely to clash, but also annoyingly redundant for the user to write out. I think a convention of "_ = added by ossapi, not the osu api" is probably fine (and I'll explicitly document _json as stable / part of the public api).

[Syriiin]

Fair enough, I imagined that was the reason, but usually a getter for that private attribute is how I would implement it.

[Liam-DeVoe]

well, the name of the getter can then also clash, so that only moves the problem somewhere else 😄

[Syriiin]

Yea I suppose... The joys of api wrappers 🙃