Api: Package Obselete for Laravel 5.3?

Created on 7 Sep 2016  路  7Comments  路  Source: dingo/api

If starting a fresh Laravel 5.3 project, is there any reason to use this versus the built-in features of Laravel?
It seems Laravel 5.3 adds a bunch of new things that make Dingo almost obsolete.

Most helpful comment

On this not, @hskrasek what do you actually think about splitting this package into smaller packages?

I was thinking like:

  • dingo/api (loads all packages and glues them nicely together)
  • dingo/transformers (and serializers)
  • dingo/routing (content negotiation, etc.)
  • dingo/errors (maybe for auto-formatting errors?)
  • dingo/auth

Why? Well, I was thinking firstly that would make it easier to swap out pieces in the future and secondly people who do not want the whole package, maybe just the routing and the error handling, could easily use only those packages and put them together themselves.

A bit like laravel does it.

Also this would mean that some parts could possibly be framework independent and just have a service provider for laravel out of the box.

Should I put this into a new issue, to discuss it further?

All 7 comments

I am not so sure this is true. It depends very much on your use case. Passport for example is very focused on having other people build applications for your API, which might not be what your use-case is.

Also I do not think Laravel comes with any kind of Transformers, does it?

Agree with @lukasoppermann. I'm still trying to use Dingo on 5.3 just for the transformers functionality. I'm struggling, but hoping i can do it as the transformers takes alot of the work out of crafting the end points

Also I do not think Laravel comes with any kind of Transformers, does it?

There is a PR for Laravel 5.4 to introduce a simple transformer https://github.com/laravel/framework/pull/14357 which I been using right now instead of Fractal with Dingo API.

Wow, 5.4 stuff already being discussed, barely have had a chance to play with 5.3. Any who, one of the main things this package offers that Laravel 5.3 or any other version of Laravel doesn't is version based routing via Accept headers. Then you have transformers, internal requests, and more. Passport kinda nullifies the OAuth2 stuff the package does, but also doesn't at the same time. Since in the future we can update our auth pieces to utilize passport.

On this not, @hskrasek what do you actually think about splitting this package into smaller packages?

I was thinking like:

  • dingo/api (loads all packages and glues them nicely together)
  • dingo/transformers (and serializers)
  • dingo/routing (content negotiation, etc.)
  • dingo/errors (maybe for auto-formatting errors?)
  • dingo/auth

Why? Well, I was thinking firstly that would make it easier to swap out pieces in the future and secondly people who do not want the whole package, maybe just the routing and the error handling, could easily use only those packages and put them together themselves.

A bit like laravel does it.

Also this would mean that some parts could possibly be framework independent and just have a service provider for laravel out of the box.

Should I put this into a new issue, to discuss it further?

@lukasoppermann Funnily enough, this has come up between @jasonlewis and myself already. No promises or anything though

May be I'll miss the point of the subject (I'm using Dingo in one of my projects, transformers could be done with Fractal package itself), but I was sure that 5.3 API functionality were done with respect of Dingo. Didn't check the L5.3 code though. Big problem was with CORS package from BarryVdH (I hope he'll excuse me for that) when routes were not registered as Laravel routes. I'm still don't understand why you decide to make own router. It's not the question, just curious

Was this page helpful?
0 / 5 - 0 ratings