Is it possible to use dynamically defined resource definitions?

[mattcrossmarc]

I have a use case in which I'd like to be able to expose a JSON:API compliant API over dynamically defined resources. For example, the resources could potentially be described via JSON schema that can be dynamically modified at runtime. From what I've found so far, JsonApiDotNetCore is primarily focused on supporting statically defined domain model POCOs and/or EF models. Sorry if I'm missing it in the code base, but have their been any discussions / efforts around support for dynamically defined resources that may change at runtime? If not, is that a use case that would be interesting for JsonApiDotNetCore?

Thanks for your help. I know this is somewhat of an edge case, so I appreciate any thoughts either way.

[bkoelman]

Can you elaborate on your use case? If the model changes at runtime, how do clients know what to fetch/update, or when/how the model has changed? And how is data accessed by the server, from some kind of unstructured key/value store?

[mattcrossmarc]

Thanks @bkoelman. The use case is a general purpose, multi-tenant storage service backed by an unstructured store (as you said) and fronted by JSON:API. Each tenant can define (and change) their schema over time, without needing to adjust the storage service. The storage service would support common data-centric capabilities and options between the API and the underlying store, such as security trimming and versioning.

[bkoelman]

Hmm, in that case, this project is probably not of much use to you. As you already noticed, the model is built at startup, similar to how EF Core works. By defining classes, developers can hook in resource-specific business logic and decorate their classes with attributes to steer behavior. It is basically a quick way to expose a database model through JSON:API, leveraging auto-generated queries.

As far as I know, this question hasn't come up before. But I don't see this happening any time soon. It would require a fundamental redesign and likely perform worse.

[mattcrossmarc]

Thanks for the feedback, and I definitely understand the mismatch. If I move the idea forward, I may credit this project for inspiring some of the API side ideas, at least. I appreciate all of the work here by you and the other contributors.

[bkoelman]

Sounds great, thanks. Would you mind adding a GitHub star to the repo?

[mattcrossmarc]

Glad to! I actually starred it last week. Thanks again.

[bkoelman]

Thanks!