flexible-presenter VS json-api

I don’t know enough about writing APIs to tell you if this would work, but we use https://github.com/AdditionApps/flexible-presenter very successfully. It has ‘preset’s which are subsets of the available fields - so where I’m displaying just user name and need their id for routing i can call the presenter with ->preset(‘listing’) to only get those fields.

There is a "Presenter" pattern for Inertia that can flatten, format or cast to arrays as part of sending your data from the back-end Controllers to the front-end Vue pages: https://github.com/AdditionApps/flexible-presenter But don't over think it. Vue can handle most of your objects, arrays and variables straight out of the controller as props. We've found that when using Inertia it's best to think of Vue as a modern form of Blade so just send the simplest props you can and do the work in the controller.

In addition to saving you time on boilerplate, the API provided by Hatchify fully implements the JSON: API specification, which stipulates solid standards to define the peculiarities of CRUD REST APIs. Get back all the time spent bike-shedding how to implement standard API features like filtering, pagination, including related data, etc. JSON: API offers consistent practices for frontend and backend developers to agree on how resources are fetched and returned. Since Hatchify provides the core of your API for you, you can count on it’s standardized functionality to give your API a consistent start.

-JSON:API format responses (https://jsonapi.org) for better standardization.

Built using Ruby on Rails, Sunnybox is designed to offer a powerful yet easy-to-use solution for developers managing email systems.

I'd really appreciate your feedback on:

- The API's user-friendliness and efficiency.

https://github.com/json-api/json-api/issues/795

There is an atomic operations extension:

JSON:API to format each message

I found json api spec[1] recently. This kind of is better standard for REST APIs. It is bit rough to handle client side but once you get the hang of it, it is breeze to use

[1] https://jsonapi.org/

That's it! Now we have a complete set of RESTful CRUD APIs at "/api/zen" that conforms to the JSON:API specification, and the access policies fully protect the APIs. The API provides rich filtering and relation-fetching capabilities. The following are some examples; you can find more details here.

Does this have any relation to https://jsonapi.org/ ?

Basic REST and JSON RPC are very simple to start with, but have common problems when application gets bigger. How do you represent relations, pagination, filtering etc? My go-to specification for structuring JSON documents is https://jsonapi.org/ It covers most basic needs of a standard API.

Easy, isn't it? The automatically generated APIs provide resource-centric RESTful endpoints using JSON:API as the transportation format. Here're a few more advanced examples of using the API: