docs/the-complete-guide/part3/customization

[giscus[bot]]

docs/the-complete-guide/part3/customization

Having APIs derived from the schema is great, but sometimes, you want to customize them to fit your needs. Some of the common use cases are:

https://zenstack.dev/docs/the-complete-guide/part3/customization

[lsmith77]

On the topic of Disallowing specific operations, it would be great to have this exposed via the model DSL. In my case we are building a read-only API. I don't really want to "abuse" the authorization concept to prevent write access, since it would then mean the endpoints exist, which creates confusion. Or is there already a plugin that can do this?

[jiashengguo]

It seems that you agree that this is not part of the authorization. Then, I'm curious about why you want to expose it via the ZModel instead of doing that in the middleware?

And what would you expect it to be expressed in the ZModel?

[lsmith77]

To me the same reasons that apply to why one would want to annotate authorization in the model apply to this. Some data should simply not be deleted or updated via the API. Putting this logic in the middleware obscures this and makes it more error-prone.

That being said, I have since learned more about ZenStack and it works very different than what I was used to with API Platform https://api-platform.com/docs/core/getting-started/#mapping-the-entities.

I assumed I would essentially annotate my models (what methods, what data etc is exposed) and that would also provide a full API and implementing methods is optional in case the default logic does not apply.

But I guess with ZenStack I do have to implement every HTTP method manually, therefore for creating a read-only API, I would simply not implement the create/delete/update methods.

So this topic can be closed.