gregschmit/rails-rest-framework

A framework for DRY RESTful APIs in Ruby on Rails.

rails-rest-framework's Issues

PUT behaves like PATCH

Issuing an update to a record via PUT behaves like PATCH, updating only the sent properties instead of completely replacing the record as would be expected. This mostly manifests when a nullable field was not originally null, but is desired to be nulled, and a PUT with new property values is sent without a null for that property.

Potentially consider a way to make PUT behave as expected, or indicate that PUT behaves like PATCH

Allow associations to be added to fields

Allow filters to define params they accept with type/descriptions

Also for pagination, perhaps we should include next/prev links?

Websockets

There is already a branch for this, but basically I want to dynamically construct ::Channel classes on each controller to allow subscribing to updates for a particular collection, and interacting with controller endpoints via action cable (or anycable).

Fix issue where singleton controllers don't get a link for the GET

Should be available, but I think I hardcoded index action, but not show, which should be available for singleton controllers because no path params are required.

Use `includes` more intelligently.

Right now, we include all associations in the model controller mixin. Rather, we should allow filters to include what they need to avoid including associations unnecessarily.

Support ordering/filtering by association properties

Probably by a designated column, but perhaps by specifying the target column, but then the issue is whether the user should have access to that column. So probably just by a designated column (perhaps name by default?).

Display allowed params (with field config) in browsable API

For most CRUD it's just the default fields, but like for DELETE it should be nothing, and then for extra fields it should just be fields defined in their config... probably?

Either way, need to be able to say "for this extra action, here are the params that are acceptable".

Batch processing

Consider adding ability to create, update, or delete multiple records at once. Perhaps there is a configuration option to determine if this is done using efficient SQL operations without callbacks/validation, or less efficient ORM operations with callbacks/validation.

Make sure enums get serialized appropriately in OPTIONS

Add metadata for validates_inclusion_in

When there is a list of valid values, add ability to annotate human-readable labels for those values.

Delegate API

We should support delegating extra actions to the underlying model for the ModelControllerMixin. Collection actions can be delegated to the model, and member actions can be delegated to records. We should either enable this via configuration or provide a configuration option in the extra_actions/extra_member_actions configuration API.

Flesh out OPTIONS API

We currently support sending fields metadata, but we should also communicate the available actions (including and making distinction for member actions) on a controller. We should also coerce more validations to top-level information on the fields metadata.