egeriis / laravel-jsonapi Goto Github PK

Hi, I'm trying to implement the example but I'm stuck here:

if (class_exists($handlerClass)) {

I'm always getting:

{"errors":[{"code":404,"title":"Entity not found"}]}

Am I missing something?

Hi all,

Not sure if this is incorrect usage or a bug, but I'm getting errors when returning error response from my customer handlers.

Example:

public function handleGet(ApiRequest $request)
{
    // ...
    return new ApiErrorResponse(404, 404, "Product doesn't exist.");
}

Because Handler.php is only looking for instances of "Response" (on Line 84), not ErrorResponse or MultiErrorResponse, it trips up when it tries to load the (non-existent) models.

I'd be happy to submit a simple PR to check for the other two response types, but I didn't know if this was the best way to go about it. Should ErrorResponse and MultiErrorResponse be inheriting from Response instead, or am I "doing it wrong"?

Thoughts?

Kyle

May I suggest introducing schema validation by using the official jsonapi schema and a library like https://github.com/justinrainbow/json-schema ?

I have been considering how to evolve this project for a while now. I find that some of the conventions could be made better and a lot of the classes have too many responsibilities.

One specific thing I've considered have been to split the project into two: query helpers and JSON API response helpers.

The thought behind this, is that I would like to easily facilitate the gathering of request parameters (e.g. include, count/page, limit, etc.) and the requested entity class to query the correct data. Also probably, the parsing of request body. In addition something like context/scope could be applied to facilitate multi-tenant database schemes. But this in itself is a big project, and something which is partially implemented and mixed into this current project.

The other part would be the JSON API response formatting, which would accept some query result and ensure to properly format the JSON response to respect the JSON API standard.

In this case, the bigger project would probably be the first. But splitting it out might make sense. At very least I think we should have a look at the project and see if we could do something to better separate the responsibilities.

Any thoughts from other users of this lib?

From \EchoIt\JsonApi\Handler::handlePaginationRequest():

        if (!empty($request->sort)) {
            $paginator->appends('sort', implode(',', $request->sort));
        }

In case sorting is done via e.g. +column (needs to be encoded to %2Bcolumn in an actual request), $paginator->appends gets called with +column which will end up in the generate url with sort= column (note the space).

It seems encoding is applied again and thus needs to be escaped first.

Unfortunately \Illuminate\Pagination\AbstractPaginator::addQuery() is sparse on what the expectence is.

But in the end the query ends up in \Illuminate\Pagination\AbstractPaginator::url() which creates $parameters, containing the query and thus the sort, and runs it through urldecode(http_build_query($parameters)).

It seems the following fixes it, but I'm not sure about this approach:

--- a/vendor/echo-it/laravel-jsonapi/src/EchoIt/JsonApi/Handler.php
+++ b/vendor/echo-it/laravel-jsonapi/src/EchoIt/JsonApi/Handler.php
@@ -468,7 +468,7 @@ abstract class Handler
             }
         }
         if (!empty($request->sort)) {
-            $paginator->appends('sort', implode(',', $request->sort));
+            $paginator->appends('sort', urlencode(implode(',', $request->sort)));
         }

         return $paginator;

Could be an oversight in the Paginator implementation?

Any chance of support for Bulk extensions?

http://jsonapi.org/extensions/bulk/

The concept of getNonBreakingErrors() is a violation of the jsonapi spec which states:

The members data and errors MUST NOT coexist in the same document.

In the specific case, a request made with includes for a relation which is not allowed must return a complete error response, not one half of the requested data and the error.

The spec says:

A server MUST respond to a successful resource creation request according to HTTP semantics.

When one or more resources has been created, the server MUST return a 201 Created status code.

But looking at this function:

    public static function successfulHttpStatusCode($method)
    {
        switch ($method) {
            case 'PUT':
            case 'POST':
            case 'DELETE':
                return BaseResponse::HTTP_NO_CONTENT;

            case 'GET':
                return BaseResponse::HTTP_OK;
        }

        // Code shouldn't reach this point, but if it does we assume that the
        // client has made a bad request, e.g. PATCH
        return BaseResponse::HTTP_BAD_REQUEST;
    }

The response code for POST case is 204, instead of 201, is this wrong? Or I'm missing something?

The project description was out-dated:

Make it a breeze to create a jsonapi.org compliant APIs with Laravel 4.

Hi! It would be great to have some scaffolding when building API. Would be cool to run something like:

php artisan generate:api Comment

which will create API controllers (extending ApiController class or so ), and routes.

Probably, you will want to set something like pagination using command options.

Laravel best practice seems to be to use snake_case for column names which is how the json keys are in turn generated out of Laravel when I hit the endpoint from browser, however somewhere in between the endpoint and browser these underscores seem to be converted to spaces which makes accessing the key hard.

Is it possible to convert the field names to camelCase on the way out and then back to snake_case on the way back in?

I just wanted to double check how a typical POST/PUT request should look like for this lib to work.

It seems you don't expect the attributes to be placed within the attributes element like below. Instead you expect the attributes simply inside data. This is easy enough to change (inside Handler->parseRequestContent()) - was there a reason why its done this way? Am i missing something?

{
"data": {
"type": "resource",
"id": "",
"attributes": {
"name": "blah blah",
"age": "5"
}
}
}

The spec follows what I've done above: http://jsonapi.org/format/#crud

Thanks mate,

Thanks

Sometimes the primary key of the models are not 'id', and I found that is being used this string instead of $primaryKey in some places.

Handler.php
      if (in_array($obj->id, $links->lists('id'))) continue;

Model.php
      $relations[$relation] = $value->id;
      /////////////////
      $relations[$relation] = array_pluck($value, 'id');

When trying to install v2.3, I'm getting the error

Your requirements could not be resolved to an installable set of packages.

Problem 1
    - Conclusion: remove laravel/framework v5.1.1
    - Installation request for echo-it/laravel-jsonapi v2.3 -> satisfiable by echo-it/laravel-jsonapi[v2.3].
    - Conclusion: don't install laravel/framework v5.1.1
    - Conclusion: don't install laravel/framework v5.1.0
    - echo-it/laravel-jsonapi v2.3 requires illuminate/pagination 5.0.* -> satisfiable by illuminate/pagination[5.0.x-dev, v5.0.0, v5.0.22, v5.0.25, v5.0.26, v5.0.28, v5.0.33, v5.0.4].
    - don't install illuminate/pagination 5.0.x-dev|don't install laravel/framework 5.1.x-dev
    - don't install illuminate/pagination v5.0.0|don't install laravel/framework 5.1.x-dev
    - don't install illuminate/pagination v5.0.22|don't install laravel/framework 5.1.x-dev
    - don't install illuminate/pagination v5.0.25|don't install laravel/framework 5.1.x-dev
    - don't install illuminate/pagination v5.0.26|don't install laravel/framework 5.1.x-dev
    - don't install illuminate/pagination v5.0.28|don't install laravel/framework 5.1.x-dev
    - don't install illuminate/pagination v5.0.33|don't install laravel/framework 5.1.x-dev
    - don't install illuminate/pagination v5.0.4|don't install laravel/framework 5.1.x-dev
    - Installation request for laravel/framework 5.1.* -> satisfiable by laravel/framework[5.1.x-dev, v5.1.0, v5.1.1].

Seems like this package is not yet for Laravel 5.1, correct?

Hi,

is there any way we can add some custom endpoints to a specific handler?

I'm talking about

POST /posts/ for creating elements
POST /posts/<<ID>>/duplicate for duplicating a specific element

When defining a second POST-route I always end up calling the same handlePost() method. Is there any solution for this scenario?

Just being serious, is this lib compliant to jsonapi.org?
E.g I'm just wondering aren't attributes not supposed to be in an attributes child? http://jsonapi.org/format/#document-resource-object-attributes. For me the lib is returning attributes as a direkt child of each object and not underneath object.attributes.

As per http://jsonapi.org/format/1.0/#crud-updating , PATCH is the actual verb to use, not PUT.

See also the FAQ: http://jsonapi.org/faq/#wheres-put