JSONAPIPlug
2.0 has moved to a protocol based approach to resource definition.
This is the result of a big refactoring, cleaning up internals and providing a more
stable foundation for the library moving forward. This means there are a number of
breaking changes that require changes to applications using JSONAPIPlug
.
See the upgrade guide in the docs for detailed upgrade instructions from 1.0.
JSONAPIPlug.Resource
is now a protocol instead of a behaviour. Using structs as resource data is now mandatory.- Moved
path
option fromJSONAPI.Resource
toJSONAPIPlug.Plug
. - Passing functions to
JSONAPIPlug.Resource
attributeserialize
anddeserialize
to customize attribute value serialization and deserialization has been replaced byJSONAPIPlug.Resource.Attribute
. - Generating per-resource
JSON:API
links and meta withJSONAPIPlug.Resource
callbacks has been replaces by theJSONAPIPlug.Resource.Links
andJSONAPIPlug.Resource.Meta
protocols. - Removed
links
option toJSONAPIPlug.API
. Resource links are always generated. - Moved the Phoenix render function to a component module in the library, this can
be added to the phoenix
MyAppWeb
module and imported in the phoenix_json.ex
module viause MyAppWeb, :jsonapi
as per phoenix conventions. - Enforce
client_generated_ids
option. This prevents sending ids in resources and included resources whenclient_generated_ids
is turned off. If you were sending ids to support resource creation with included atomically, this is now supported by sendingJSON:API 1.1
lid
in relationships and included resources. This is supported even though the reported jsonapi vesion is still1.0
because the library still doesn't have fullJSON:API 1.1
support. Onlylid
is supported.
Contributors: @lucacorti @treere
- Fix case in deserialization of relationships (@treere)
- Fix deserialization of many relationships (@lucacorti, @alexgolasibill)
- Allow disabling generation of links for relationships and includes. (@treere)
- Add compile time optimizations for case transformation of resource fields (@treere)
- Add support to restrict allowed includes to
JSONAPIPlug.Plug
. (@lucacorti)
- Fix deeply nested includes not always serialized correctly (@treere)
- Accept id along with attributes in default sort parser implementation (@agos)
- Remove deprecated builder_opts() usage from Plug.Builder (@lucacorti)
- Cache configuration (profiling by @treere, @lucacorti)
- Relax :nimble_options dependency (@lucacorti)
- Allow nimble options 1.0 (@lucacorti)
First release of jsonapi_plug
: JSON:API
library for Plug and Phoenix applications.
This project was born as a fork of the jsonapi library but has since been completely rewritten and is a different project.
What jsonapi_plug
has to offer to users of Phoenix/Plug for building JSON:API
compliant APIs:
- An extensible system based on behaviours to convert
JSON:API
payloads and query parameters from/to whatever format best suits the library user. Default implementations are provided to convert payloads and query parameters to an Ecto friendly format, which is probably the most common scenario for the data source of APIs in Phoenix based applications. Behaviours are available to customize parsing and/or easily parse non-standard specified query parameters (filter, page). - Ability to have multiple APIs with different configurations sourced from the hosting application configuration to avoid single global configuration rigidity. This allows to serve multiple different APIs from a single Phoenix/Plug application instance.
- A declarative resource system allowing users to control rendering, rename fields between
JSON:API
payloads and internal data, customize (de)serialization of fields values and more without writing additional business logic code.
Contributors: @lucacorti