yahoo
Refactor JSON API support out into its own module
When we added GraphQL support we added it in its own module, to prevent concerns with GraphQL's old licensing terms from dissuading people from adopting Elide. However this approach may make sense as a general pattern.
If we refactor JSON API support (the JAX-RS endpoint) out of elide-core into a separate elide-json-api module then we open the gates for adding other transports as well (perhaps we later add elide-protobuf or elide-thrift modules).
I vote for this feature. We use elide as a true middleware, and it is wrapped by Spring (boot). Elide's architectural pattern of entity-driven, lifecycle events and very nice security framework are all cool things we want to use, but on the transport layer, we don't want to be necessarily tied to either JSON API or GraphQL. A Protobuf module would be a very nice add-on to have, as we want to use GRPC for our inter-service communication on the backend. With the added flexibility, Elide could be a very powerful and flexible tool to build all kinds of specification and transport-independent APIs.
👍 You mentioned you had made modifications to Elide.java. Is that something that is worth submitting back? I haven't given this restructure a whole lot of thought yet.
I extended ElideResponse and Elide simply to get the JsonNode out. It's a very minor change and I am sure will no longer be necessary when the JsonApi module is refactored out of Elide core.