Laravel-json-api: Non-Resources Example + Different Headers Acceptance

Created on 22 Aug 2018  路  4Comments  路  Source: cloudcreativity/laravel-json-api

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

  1. How to format these kind of endpoints? It doesn't have an id of course, so how would this work in jsonapi? Maybe an meta-only object? Do you maybe also have an example for this?
  2. When we change the Accept-header we don't want to duplicate our endpoint. However with this framework, how can you still check for valid accept headers and return csv or json based on the header?

Keep up the amazing work!

enhancement

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 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.

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/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.

All 4 comments

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 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.

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/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

Was this page helpful?
0 / 5 - 0 ratings