JSON API integration

Yes, that sound good !! I try to found time to purpose a prototype to test it fasT.

Hello, I also need the image-crop relationship!!

I come back to this subject today, I'll try to purpose a relationship fast.

hii @berdyshev

The permission "administer crop" is required to get the crop entity (/jsonapi/crop/focal_point/{uuid?})

This seem's not be an Crop API issue because this storage entity isn't not designed to only work with "focal_point" concept but more Crop zone in space. I see more anything like (/jsonapi/crop/{uuid?}) or (/jsonapi/crop/{crop_type}) for final endpoint ?

I need to test more but normally all entities 'standard' does work with jsonapi discover no ? I come back fast with information about that ...

Another thing the possibility to create crops for given uri sound great IMHO with jsonapi / graphQL integration ? We need to see what you need to achieve that wonderfull feature for API-first app building by Drupal.

I test Crop api basic integration. Actually Crops are available with "api/crop/{crop_type}" and "api/crop/{crop_type}/{uuid}"

Here you have a small representation of what that endpoint can display :

{
    "data": [
        {
            "type": "crop--crop_16_9",
            "id": "4345d944-c5e8-4611-a596-7fc1f1f530ac",
            "attributes": {
                "cid": 1,
                "uuid": "4345d944-c5e8-4611-a596-7fc1f1f530ac",
                "vid": 1,
                "langcode": "en",
                "entity_id": 230,
                "entity_type": "file",
                "uri": "public://2017-10/Bibury-England.jpg",
                "height": 544,
                "width": 973,
                "x": 1831,
                "y": 1008,
                "revision_timestamp": 1509093093,
                "revision_log": null,
                "default_langcode": true
            },
            "relationships": {
                "type": {
                    "data": {
                        "type": "crop_type--crop_type",
                        "id": "fe390f76-5b54-451d-968b-d139b626020f"
                    },
                    "links": {
                        "self": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac/relationships/type",
                        "related": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac/type"
                    }
                },
                "revision_uid": {
                    "data": {
                        "type": "users",
                        "id": "11f483d2-a1fb-47f0-9e11-ffb21f014f62"
                    },
                    "links": {
                        "self": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac/relationships/revision_uid",
                        "related": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac/revision_uid"
                    }
                }
            },
            "links": {
                "self": "http://contenta.local/api/crop/crop_16_9/4345d944-c5e8-4611-a596-7fc1f1f530ac"
            }
        }
    ],
    "links": {
        "self": "http://contenta.local/api/crop/crop_16_9"
    }
}

I admit in this state this is not really pretty and easy to use in contenta context or simple jsonApi context.

We need to have more reflexion about where we need to access Crop ressources ? IMHO the best place is a relationship onto File representation ? or directly at basis of field_xxxx data ? Like

                "image_cropped": {
                    "data": {
                        "type": "files",
                        "id": "bb03b3b7-b27e-41a4-bdba-401d714af8b5",
                        "meta": {
                            "alt": "",
                            "title": "",
                            "width": "2560",
                            "height": "1600"
                            >>>>"crop": "my_crop_type" or uuid or true / false to be sure that ressource contain a link with crop<<<<
                        }
                    },
                    "links": {
                        "self": "http://contenta.local/api/pages/64bed44b-8cc1-40c8-9d22-03cb5e91b100/relationships/image_cropped",
                        "related": "http://contenta.local/api/pages/64bed44b-8cc1-40c8-9d22-03cb5e91b100/image_cropped"
                    }
                }
            },

I'm really open to all suggestions about how crops can be integrated ?

As you can see, there are no relationship or attributes related to the Crop data. That's why I need to make another request to /jsonapi/crop/focal_point?filter[entityId][condition][path]=entity_id&filter[entityId][condition][value]=651 and get these details:

The main problem of that, is this work only in Focal Point approach and here we need more robust and common implementation.

In #decoupled slack room we have started to found solutions because Crop are a hard problem to be managed with JsonAPI (@see this excellent article ==> https://www.lullabot.com/articles/decoupled-drupal-hard-problems-image-s... ).

Here you are the discuss from Slack on that subject :

First thing with @dawehner

dawehner [17 h 31]
@woprrr Have you seen how the
```consumer_image_styles```
module exposes image style urls? I'm wonderin whether you could do something similar

Second part on #decoupled room :

gabesullice [15 h 33]
@woprrr I'm happy to talk it through with you. We had some discussions about handling image styles in the JSON API module and decided against including anything like a relationship to a styled version of the link. Including putting something in the "meta" section.

[15:36]
The general conclusion was that image styles/crops are a presentational decision and therefore should not be included in the data returned in the response.

woprrr
[17 h 03]
@gabesullice In this case that should be great to add relationship onto Files ?

[17:03]
That seem’s hard to make a link with crop and files at this current state

gabesullice [17 h 06]
I think the only way to add a relationship onto an entity is to add a computed entity reference field

[17:06]
there's really no way to hook in and add one @woprrr

Another suggestion is why not expose ALL crop types effects and filter crops by specific rights ? (Only a suggestion to found better solution...).

@gabesullice Have you an example or whatever usefull to illustrate your idea ?

@woprrr, unfortunately, I don't have an example for creating a computed field that I can share. To do so, you will need to implement hook_entity_type_build_alter and add a new field definitions to all the entities which have image fields. To be clear, I think this is a bit of a hack, but it would "get the job done".

If you read @e0ipso's blog, you might be able to take some inspiration from his module, https://www.drupal.org/project/consumer_image_styles.

This overrides the image field normalizer to add "meta" information about image styles. This is most like your proposal for the JSON output. Unfortunately, this method only works when one module overrides the normalizer. I.e., multiple modules trying to add different information under the "meta" key will conflict with one another.

> This overrides the image field normalizer to add "meta" information about image styles. This is most like your proposal for the JSON output. Unfortunately, this method only works when one module overrides the normalizer. I.e., multiple modules trying to add different information under the "meta" key will conflict with one another.

That is the sad truth. However we can use service decorators to play nicely. I'd love to review a patch in that direction if that's not the case (I can't remember now).

Hi,

For information, there is a related issue in Entity Share #3220320: Support Crop API.