Roadmap

[beauby]

As discussed, here's what I've been working on. cc @NullVoxPopuli

What's there so far (beauby):

• Generators for serializable/deserializable classes based on ActiveRecord models.
• Rails-tailored versions of JSONAPI::Serializable::Model and JSONAPI::Deserializable::Resource.
• Rails plumbing for rendering render jsonapi: foo, with (optional) automatic serializable class inference.
• Example app: jsonapi_twitter (forked from jsonapi_suite/jsonapi_twitter).

Also, what's been done in other places for that to work:

• Implement JSONAPI::Serializable::Model (subclass of JSONAPI::Serializable::Resource focused on resources that are direct representations of models), with API versioning-aware serializable inference.
• Improve JSONAPI::Deserializable::Resource DSL – less magic, more power.

What I'd like to see done:

• Add support for render jsonapi_errors: foo, and automatic handling of AR validation errors and such.
• Add links inference for JSONAPI::Serializable::Model.
• Ensure API versioning support is working as intended.

[NullVoxPopuli]

We probably need to start merging the PRs :-) I'll do some code review when I get home later tonight (6-7 hours from now)

is render jsonapi_errors: foo really required? I think best case 'Railsy' way of doing it would be to render jsonapi: model and and have it auto-determine if there are errors and render the errors?

For api versioning, what are you thinkin' here? as far as i'm aware, everything is explicitly called so far. Unless we want to do a serializer lookup, like what AMS has? I'd be down with that.

Also Sidenote -- the more this gets fleshed out, the more I think AMS would just become a super thin wrapper for jsonapi-rails and just add support for the current json and attributes adapters where teh jsonapi adapter would be straight passthrough.

[beauby]

Serializer lookup is already implemented in JSONAPI::Serializable::Model, as well as API versioning.

Regarding errors, that is a possibility, but we must support custom errors as well.

Regarding AMS: yeah, that's a possibility, though I'm not sure what the value would be, as it is currently a pain to use different adapters simultaneously in AMS.

[NullVoxPopuli]

Serializer lookup is already implemented in JSONAPI::Serializable::Model, as well as API versioning.

ah ok, cool. I haven't looked at that yet.

Regarding errors, that is a possibility, but we must support custom errors as well.

Maybe jsonapi: model, error_serializer: WhateverErrorSerializer?

Regarding AMS: yeah, that's a possibility, though I'm not sure what the value would be, as it is currently a pain to use different adapters simultaneously in AMS.

agreed -- my motivation here is to greatly simplify AMS while still moving forward with the cleanup of it. And to keep things somewhat compatible current (proper) use.

[beauby]

Maybe jsonapi: model, error_serializer: WhateverErrorSerializer?

Errors are not limited to model validation errors, so that would not work. Errors in general are objects that respect the JSONAPI::Serializable::Error API (which is simply #as_jsonapi at the moment).

[beauby]

The interesting PRs in the other projects are:

• https://github.com/beauby/jsonapi-serializable/pull/3
• https://github.com/beauby/jsonapi-deserializable/pull/3

[NullVoxPopuli]

maybe the jsonapi renderer could detect when model (in this case) is of type `JSONAPI::Serializable::Error and just render with that?

[beauby]

maybe the jsonapi renderer could detect when model (in this case) is of type `JSONAPI::Serializable::Error and just render with that?

That is not possible because it is intended to be just an interface, not a required parent class. Plus, it seems sensible to me to knowingly respond with errors rather than with a success document.

[NullVoxPopuli]

yeah hmmm