He Chris,
First of, amazing how you've progressed and building something so amazing. Almost version 1.0.0. 馃憤
I would really want to use jsonapi overal but I just keep stuck on 2 concept and I hope you have an example/answer for this:
As example take this call https://developers.messagebird.com/docs/reporting, which is a /reporting resource which can also return csv-format instead of json if you change the accept header
Keep up the amazing work!
Hey! So here's comments on both the issues you've raised:
These are totally possible at the moment, and should just be added as normal Laravel routes. The package already allows JSON API replies to be constructed on other controllers, I probably just need to add a demo, docs and tests. I'll have a look at doing that soon.
And yes, if the returned value is not a resource with an ID, I'd return the info in the meta key. The JSON API spec specifies that a document (the response body) must contain at least one of data, meta or errors in the top-level, so returning a response that only has meta in it is totally valid according to the spec.
This is something I'd love to add in, particularly because we have scenarios like this in our applications. At the moment we just stand these up on different routes, i.e. normal Laravel routes. But what you are asking for would be a much nicer implementation.
The main blocker on this is I used the neomerx/jsonapi codec matching implementation for content negotiation which was clunky to integrate with Laravel. Now that I've switched to only developing JSON API for Laravel (and hopefully Lumen in the future), it would make sense to do the content negotiation in a more Laravel specific way. And then allow developers to add in support for other Accept types.
I'll have a think about how it could be implemented but let me know if you've got any ideas on how you'd like it to work. I'm working on a project at the moment that has data exports as well, so this would be a good time to sort this out.
Thank you for your extended response. So far don't have an concrete idea. Maybe an a Middleware which defaults to jsonapi header only. But ill think about it. As for Non-resource endpoints: meta object should do
We're working on this now as we need to use this feature in 1.0.
I've now added support for different media types, and this is documented here:
https://github.com/cloudcreativity/laravel-json-api/blob/develop/docs/features/media-types.md
Will be released in 1.0.0-rc.1
Most helpful comment
Hey! So here's comments on both the issues you've raised:
Non-Resource Endpoints
These are totally possible at the moment, and should just be added as normal Laravel routes. The package already allows JSON API replies to be constructed on other controllers, I probably just need to add a demo, docs and tests. I'll have a look at doing that soon.
And yes, if the returned value is not a resource with an ID, I'd return the info in the
metakey. The JSON API spec specifies that a document (the response body) must contain at least one ofdata,metaorerrorsin the top-level, so returning a response that only hasmetain it is totally valid according to the spec.Other Accept Types
This is something I'd love to add in, particularly because we have scenarios like this in our applications. At the moment we just stand these up on different routes, i.e. normal Laravel routes. But what you are asking for would be a much nicer implementation.
The main blocker on this is I used the
neomerx/jsonapicodec matching implementation for content negotiation which was clunky to integrate with Laravel. Now that I've switched to only developing JSON API for Laravel (and hopefully Lumen in the future), it would make sense to do the content negotiation in a more Laravel specific way. And then allow developers to add in support for other Accept types.I'll have a think about how it could be implemented but let me know if you've got any ideas on how you'd like it to work. I'm working on a project at the moment that has data exports as well, so this would be a good time to sort this out.