[Feature request] Standard REST routes for @zenstackhq/server

[jawadst]

Is your feature request related to a problem? Please describe.

The REST routes generated are pretty unusual and closer to RPC than REST as the verbs are present in the path instead of the resources. /findMany, /findUnique, /create, etc. are not standard in REST.

Describe the solution you'd like

I'd love more standard REST routes based on collections of resources:

GET /model/findMany -> GET /models
GET /model/findUnique -> GET /models/:id
POST /model/create -> POST /models
PUT /model/update -> PUT /models/:id and PATCH /models/:id
DELETE /model/delete -> DELETE /models/:id`

This also requires defining a collection name (models) from a resource (or model) name (model). That could be an attribute of the model so that it can be configured by the developer.

To make it even more standard, it'd be great to adopt https://jsonapi.org/ for the structure of the HTTP requests and responses.

[ymc9]

Thanks for the proposal @jawadst !

I had two conflicting goals in mind when working on the server APIs 😂:

1. Preserve Prisma's power and query syntax
2. Provide a RESTful (or at least REST-like) API

And I chose #1 mainly to make it easy for Prisma users to use it.

Giving it a second thought, it probably doesn't hurt to provide RESTful APIs alongside the "Prisma" ones. Maybe best in a separate package like @zenstackhq/rest. It can be compliant to jsonapi.

When consuming such API, do you feel you still need Prisma's flexibility for nested fetch and update for relations? Just wondering how much of that power needs to be reflected on the REST side.

[jawadst]

Thanks for looking into it and for providing context. To your point, I assumed "server" meant "REST" but that was not your goal so that makes sense.

When consuming such API, do you feel you still need Prisma's flexibility for nested fetch and update for relations? Just wondering how much of that power needs to be reflected on the REST side.

I am generally not interested in the nested fetches or update for relations and I am looking for a simple (yet complete) REST implementation. I am comfortable with doing more HTTP requests to query nested data, and I generally value the standard more than saving on some HTTP requests (I recognize that's a personal preference though). JSONAPI goes further and does support nested fetches if you think that has value generally.

[ymc9]

Got it. Thanks for sharing your thoughts. I'll think about it and see how to balance flexibility and RESTful-ness.

Is this blocking you right now? Would be great to know a bit more about your potential use of ZenStack (if not confidential) so we can prioritize properly.

[jawadst]

@ymc9

Is this blocking you right now? Would be great to know a bit more about your potential use of ZenStack (if not confidential) so we can prioritize properly.

I was evaluating Zenstack as an option for writing new API microservices at our company. We currently use Feathers and Nest but I am interested in an alternative where most of the work is done automatically from a Prisma schema which is how I found Zenstack. Nothing urgent but it is blocking in the sense that we'd require a REST API rather than the current API format that Zenstack supports for consistency with our existing APIs.

I have a PR that adds initial support for REST in Zenstack: #326
It still misses quite a few JSON:API features but I am interested in feedback on the architecture changes and the initial changes.

[ymc9]

Thanks a lot for sharing the background and creating the PR! I'll look into it, and we can continue more detailed discussions there. Just in case you haven't joined, you can find us on discord as well: https://discord.com/invite/Ykhr738dUe

[ymc9]

Added in release alpha.119