lode/jsonapi

Human-friendly library to implement JSON:API without needing to know the specification.

jsonapi's Issues

Accept a collection as to-many relation in a resource

Right now, a resource->add_relation() accepts another resource object. It would be nice if it can accept a collection object as well, setting multiple ids.

Keep 'relationships' and 'meta' for included resources

As noted by @Pierozi in #17 (comment), we now unset relationships and meta when adding an included resource: https://github.com/lode/jsonapi/blob/master/src/response.php#L255. This should not be done. Resource objects inside the included array should just be the full representation.

check key primary_links['self']['href']

I noticed following on line 281 in resource.php:

$base_url = (isset($this->primary_links['self']['href'])) ? $this->primary_links['self']['href'] : $this->primary_links['self'];

$this->primary_links['self']['href'] never seems to exist (at least not href), can't find where ['href'] should be set, but that put aside :)
$this->primary_links['self'] is a string, and ...['href']seems to substring that, resulting in "/", and thus true, and thus using "/" as $base_url.

When I add an additional check to see if primary_links['self'] is an array, it seems to work as intended (line 281+303):

// $base_url = (isset($this->primary_links['self']['href'])) ? $this->primary_links['self']['href'] : $this->primary_links['self'];
$base_url = (is_array($this->primary_links['self']) && isset($this->primary_links['self']['href']))
	? $this->primary_links['self']['href']
	: $this->primary_links['self'];

Allow include in included and data resourses with same id

Say, I have resource structure like this:

{
    "data": [
        {
            "type": "news",
            "id": "item1",
            "attributes": {
                "title": "item1"
            },
            "relationships": {
                "also": {
                    "data": [{
                            "type": "news",
                            "id": "item2"
                        }]
                }
            }
        },
        {
            "type": "news",
            "id": "item2",
            "attributes": {
                "title": "item2"
            },
            "relationships": {
                "also": {
                    "data": [{
                            "type": "news",
                            "id": "item3"
                        }]
                }
            }
        }
    ]
}

And I want to get resources like this:

{
    "data": [
        {
            "type": "news",
            "id": "item1",
            "attributes": {
                "title": "item1"
            },
            "relationships": {
                "also": {
                    "data": [{
                            "type": "news",
                            "id": "item2"
                        }]
                }
            }
        },
        {
            "type": "news",
            "id": "item2",
            "attributes": {
                "title": "item2"
            },
            "relationships": {
                "also": {
                    "data": [{
                            "type": "news",
                            "id": "item3"
                        }]
                }
            }
        }
    ],
    "included": [
        {
            "type": "other_companies",
            "id": "item2",
            "attributes": {
                "title": "item2",
                "link": "link",
                "code": "item2",
                ...
            }
        }
    ]
}

For now there will be triggered error "can not have multiple resources with the same identification".

Can we add individual id validation for included?
Just make another claimUsedResourceIdentifier for included.
Or add option for validator.

Problems using ResourceDocument::fromObject

Hi, we use your implementation quite a lot in our projets, and until now, never had any problems (we appreciate your work tremendously).
But now we have problems with answering a PUT request.
using your code leads to a structure were the attributes of an ResourceObject more or less look like this

"data": {
"type": "Event",
"id": "196",
"attributes":{
"type": "Event",
"id": "196",
"attributes": {
"ClientID": 1
}
}
}
which leads to an exception (type already used)

A solutions which works for us is simply:
rewriting the function in ResourceDocument in this way:

public static function fromObject($attributes, $type=null, $id=null, array $options=[]) {
$resourceDocument = new self();
$resourceDocument->setPrimaryResource($attributes->getResource(), $options);
return $resourceDocument;
}
the document includes now all links, relationships, and so on, from the ResourceObject

Validation for query parameters (include, sparse fieldset, sort, page, filter)

Next to parsing (#44) there's a lot of validation to do around query parameters. Mainly around which are supported by the server.

Spec 1.1 RC 2: make it easy to add describedBy links at root level

failed to generate json: Recursion detected

When i implement exception in controller, like examples:

$exception = new \Exception($message='user not found', $code=404);
$document = ErrorsDocument::fromException($exception);
$document->sendResponse();

I've got the error: failed to generate json: Recursion detected

I'm trying to use this on Lumen. I'm doing something wrong?

Spec 1.1 RC 2: add support for Local Ids

Adding objects as meta values to an error object fails

As it uses the base class' protected method while not extending the base class.

Support v1.1 of the specification

After v2 (#36) of this library is released, v1.1 of the spec can be implemented.

Import a database array as a collection response

It would be nice to do something like this:

$results = 'mysqli_query() + fetch_assoc() while-loop';
$jsonapi = new jsonapi\collection($type='users');
$jsonapi->import_from_array($results);

And maybe a way to split keys as relationships. Like import_from_array($array, $split_relation_names) or $array = collection::split_relations($array, $relation_names).

Validation for received document structure

Next to parsing (#5) there's a lot of validation to do around the document structure. And optionally also about which values are understood.

JSONP

I experience an unexpected result when trying use the JSONP option:
I used jQuery for this test:
$.getJSON('https://my.otherdomain.com/v1/myresource/123/?callback=?',response=>console.log(response))
resulting in this request:

https://my.otherdomain.com/v1/myresource/123/?callback=jQuery110209372736821749224_1518011758243&_=1518011758244
Accept:*/*

My API responses JSONP requests with:
$jsonapi->send_response(jsonapi\response::CONTENT_TYPE_JSONP, null, null, $this->getJSONPCallback());

What happens is that plain JSON gets returned, meaning not being wrapped the callback function.

I've debugged this, and noticed JSPN gets 'called off' in this if-block, resetting $content_type and thus not being treated as JSONP afterall, due to strpos($_SERVER['HTTP_ACCEPT'], '/json') check:
response.php line 165

	if (base::$debug || strpos($_SERVER['HTTP_ACCEPT'], '/json') == false) {
		$content_type = self::CONTENT_TYPE_DEBUG;
	}

Non-error responses could have a http status code as well

I.e. for 201 Created or 204 No Content.

It would be nice to also support sending out redirect locations for 30x status.

Parse requests for creating, updating and deleting resources

Provide some help for incoming jsonapi formatted data, methods which help you understand the incoming data.

Spec 1.1 RC 2: support extensions and improve support for profiles

Problem with Content-Type: application/vnd.api+json

When I want to response a code 204 No content the Content-Type is text/html; charset=UTF-8 (according to postman).

Content type should be always application/vnd.api+json even if there is no data, right?. I don't know if this is an issue, because I'm newbie with jsonapi.

My code to send response is: $document->sendResponse(http_response_code(204));

Dependency Injection (using pimple )

I was wondering how can I use the following library with pimple ?
great one BTW ;)

Sync links with the latest spec

Right now links are represented using the old syntax:

{
    "self": "http...",
    "foo": "bar"
}

The latest spec says it should be like this:

{
    "href": "http...",
    "meta": {
        "foo": "bar"
    }
}

Links can anyway be added as strings, in both spec versions and this is supported.

Allow to disable the automated links for relationships

As not all servers might implement them.

Parse request options: sparse fields, sorting, pagination, filtering

Next to generating documents we could also parse request options from a client to make it easy to understand what was requested.

Spec 1.1 RC 2/3: add support for new properties of the link object

• rel
• describedby
• title
• type
• hreflang

Possibility to remove the automated self-link

Or in general more flexibility for self-links.

Allow to mask internal server errors as 503 status

add_relation in resource.php overwrite (array relations)

While upgrading from an earlier version, I noticed a change in resource.php, function add_relation

On line 270 it handles array input like this

	if (is_array($relation)) {
		$this->primary_relationships[$key] = $relation;
	}

But this is overwritten on line 312 (outside the if closure), with the variable $relation_data that is not defined in that case:

$this->primary_relationships[$key] = array(
		'data'  => $relation_data,
	);

This breaks implementations who pass the relation as array.