Multiple fixes for REST, Wiki and JsonAPI storage clients

The current code has been tested with success with the following endpoints:

• https://www.rijksmuseum.nl/api/en/collection
• https://www.drupal.org/api-d7/node.json →
• https://en.wikipedia.org/w/api.php

I'll put tomorrow the settings used.

Add support for JSON:API.

3 new working examples:

Json API example:

-storage client: JSON:API
-Endpoint: http://your.server.org/jsonapi/content_type/bundle_name/ (ex.: http://your.server.org/jsonapi/node/page/)
-Estimated total number of entities: 100
-Parameters: (empty)
-mapping:
JSONPath field mapper
ID: $.id
UUID: $.id
Title: $.attributes.title
Note: Drupal JSON:API endpoint does not provide a way to count entities so we set a static value that should correspond to the number of available entities.

BrAPI example:

-storage client: REST
-Endpoint: https://www.musabase.org/brapi/v1/germplasm/
-The endpoint URL (list) provides full entities: checked
-URL for a single entity (optional): https://www.musabase.org/brapi/v1/germplasm/{id}
-URL to get the total number of available entities (optional): (empty)
-Response format: json
-JSONPath leading to the list of entities (optional): $.result.data.*
-JSONPath leading to the content of a single entity (optional): $.result
-Single entities are keyed by their ID in a list: unchecked
-JSONPath leading to the total number of available entity (optional): $.metadata.pagination.totalCount
-Default number of items per page used by the endpoint or maximum number of entities supported in a single query: 50
-Page parameter: page
-Page parameter type: Page number
-Page size parameter: pageSize
-Page size parameter type: Number of items per page
-Page numbers and entity numbers start from one: unchecked
-Authentication type: No authentication needed
-Additional HTTP headers: (empty)
-List parameters: (empty)
-Single entity parameters: (empty)
-mapping:
simple field mapper
ID: germplasmDbId
UUID: germplasmDbId
Title: germplasmName

Games of Throne example:

-storage client: REST
-Endpoint: https://www.anapioficeandfire.com/api/houses
-The endpoint URL (list) provides full entities: checked
-URL for a single entity (optional): (empty)
-URL to get the total number of available entities (optional): 444
-Response format: json
-JSONPath leading to the list of entities (optional): (empty)
-JSONPath leading to the content of a single entity (optional): (empty)
-Single entities are keyed by their ID in a list: unchecked
-JSONPath leading to the total number of available entity (optional): (empty)
-Default number of items per page used by the endpoint or maximum number of entities supported in a single query: 50
-Page parameter: page
-Page parameter type: Page number
-Page size parameter: pageSize
-Page size parameter type: Number of items per page
-Page numbers and entity numbers start from one: *checked*
-Authentication type: No authentication needed
-Additional HTTP headers: (empty)
-List parameters: (empty)
-Single entity parameters: (empty)
-mapping:
String functions and JSONPath field mapper (plugin)
ID: preg_replace('#.*/(\d+)$#', '$1', $.url)
UUID: preg_replace('#.*/(\d+)$#', '$1', $.url)
Title: germplasmName
Note: see documentation https://github.com/joakimskoog/AnApiOfIceAndFire/wiki/

Thanks for all the work @guignonv I am not really in favor of mixing different issues into one big change. It makes it harder to review and discuss. I much prefer to solve the issues in separate issues instead.

Fixed original tests.

@pefferen, I agree on what you said. The problem I see here, is that all those issues are strongly linked and related to REST client. A fix for one could conflict a fix for another. In fact, I had a look to a couple of those issues and even made some PR for fix (as you may have seen) but I realized that they were conflicting (or not efficient) and in fact, a global refactoring was needed. That's why I can to a "multi-fix" solution. I hope you understand my perspective.

For sure, it is harder to review and harder to validate but I don't see a simple way to split this multi-fix for each issue. In my opinion, the only problem of this multi-fix is the changes it brings on the API. If people implemented their own REST clients, they may have to change their code a little. For me, that's the only concern. For the rest, the existing features of the REST/Wiki/JSON:API clients are there with more possibilities. I'm think of adding some doc on how to implement a REST client (with what should be fixed on older clients regarding the paging) to address that.

I also think I should add more tests for the new features added. I'll put it under review once I'm done.

I've completed tests and the code should now be quite stable and reliable while some tests would still need to be written.

If people could review the patch and validate it, it would be greate.

Once validated, @pefferen and other external entities module maintainers, please merge these fixes so I/we could work on other aspects.
Think of it this way: instead of spending let's say 3 minutes to review each of the listed issues here, which would mean more than 45 minutes, just review and merge this one and it will solves the others (maybe just one will not be fixed but I noted other old issues not listed here that should be fixed by this as well). Then I will be able to mark the other issues that I am sure are fixed as "fixed" with a little text referring to this issue and its corresponding commit so we could reduce the number of opened issues...

Added patch for people not using the fork.

The last submitted patch, 16: 3427686-multiple-fixes-for.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Fixed test issues (forgot to commit changes on tests).

The last submitted patch, 19: 3427686-multiple-fixes.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

The last submitted patch, 22: 3427686-multiple-fixes.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Tests are passing on my side. :-S (running with PHPUnit 9.6.16, PHP 8.1.27 (cli), Drupal 10.2.2)
Any idea why the "edit-ref-0-actions-delete" (or "ref_0_remove_button") button is not found when running on DrupalCI?
Could it be a Drupal version problem?

Updated patch to support D10 and D9.

Could someone from the external entities module maintainers review this issue and if ok, merge it to the current dev. I got colleagues who need this patch to be applied and I also need to work on other features that require this patch to be applied. I would really appreciate if it could not take months. Pleeeaaasse! :-) Thanks.

New alternate proposal: I'd like to add more features and breaking changes (see ✨ Better support for query filtering and data saving Active ). What about creating a v3.0.0 branch on which I could work?

This has been fixed on v3 (3.0.x branch) by commit 45f3708dc9f5579672e93fb301766aabbb17fd1f.

Automatically closed - issue fixed for 2 weeks with no activity.