Create custom API Handler ver 3.5

Feature Requests
1

Describe the problem you would like to solve

We are currently working at a open peer review platform for preprints. For this we developed a set of 3 plugins for OPS which depend on a custom API:

1. Open Peer Review plugin (not published yet)
1. customMetadata plugin (GitHub - felixhelix/customMetadata)
2. userComments plugin (not published yet)

The first two plugins use an API to allow editing of data in the submission and publication stage, the third one to allow user interaction on the preprint details page.

Both are essential for our open peer review service to work. However, in OPS 3.5 the option to create custom APIs is discontinued.

Describe the solution you’d like
Touhidur Rahman already created a proof of concept solution Issues · pkp/pkp-lib · GitHub

Who is asking for this feature?
As stated above, the feature is essential for our service to work. The open peer review platform is a project by the University Library of Cologne, funded by the German Research Foundation and realized in cooperation with several associations of social scientists.

2

@felixhelix after some discussion about this with other dev team members, we have decided to implement this feature and move forward with already created proof of concept . Please keep an eye at github issue Allow plugins to construct and expose own API endpoints · Issue #9434 · pkp/pkp-lib · GitHub for it to get implemented and merged to the core .

Regards
Touhidur Rahman
PKP Team

1 Like
3

Thanks so much for your help with that :))

4

A bit more background details about this feature

This feature/behaviour already exists in the 3.3 and 3.4 release and only been removed in the current main which is upcoming 3.5 . As we refactor all the API routes to use the Laravel routing toolset and removed the Slim framework, the dependent code of this functionality also removed in the current main branch . We had the proof of concept ready immediately but did not find any use case of this functionality, so we did not move forward with it .

After the original forum post at Create API Handler OPS 3.5 which lead to this feature request, we had some discussion within the dev group and quite a few member was interested to bring this back and keep it in the upcoming main . That lead to the decision to bring back and reimplement this functionality which was kind of removed because of a regression.

1 Like
5

@felixhelix the work is done but before merging, we would like to get some feedback based on real use case. Can you please check the example plugin at GitHub - touhidurabir/apiExample: An example plugin to show how to implement plugin level API endpoints for OJS/OMP/OPS. Only compatible if https://github.com/pkp/pkp-lib/issues/9434 merged . if that cover up all the use cases that your plugins can have ? Also if interested, check the actual implementation at Allow plugins to add/modify API endpoints of existing entity · Issue #9434 · pkp/pkp-lib · GitHub

Regards
Touhidur Rahman
PKP Team

6

Thanks @touhidur !
I managed to update our comments plugin, so that the API now works with 4.5 (cherry-picking your commit) :slight_smile:
I did not start with updating our other plugins, however, but I think I can apply this procedure to the other plugins as well.

I also found two other plugins, that make use of a custom API:

One question: It seems to me that you can only override / extend an existing API controller, such as user or submission, but not create your own? Or did you just use one of those for simplicity?

Yours
Felix

7

One question: It seems to me that you can only override / extend an existing API controller, such as user or submission, but not create your own? Or did you just use one of those for simplicity?

@felixhelix To clarify this part if I understand correctly

What is possible :

  1. Override/Modify an existing api routes on existing entity (e.g. users, submissions, etc) to provide different response or execute different actions . For example, http://BASE_URL/index.php/CONTEXT_PATH/api/v1/users/report provide a report data in CSV format but possible to override that behaviour to get different response or action .

  2. Add one or multiple new route/s on existing entity (e.g. users, submissions, etc) that can handle different actions. For example, the example plugin provide such example like a totally new route on users entity as http://BASE_URL/index.php/CONTEXT_PATH/api/v1/users/testing/routes/add . Note that testing/routes/add does not exist on users entity by default .

What is not possible :
Plugins to have their very plugin specific own routes like http://BASE_URL/index.php/CONTEXT_PATH/plugins/generic/apiExample/api/v1/tests . see that part plugins/generic/apiExample which follows the plugin level convention of PLUGIIN_PREFIX/PLUGIN_CATEGORY/PLUGIN_NAME . We initially have this one included in the initial proof of concept implementation but removed it as it adds a lot of complexity to api router and handler .

If your question related to section What is not possible, then yes, thats not possible right now and removed from initial proof of concept . But if there is any use case which can be highly benefitted from it, we would love to have know about it .

Regards
Touhidur Rahman
PKP Team

8

@touhidur Thanks for your detailed reply! Yes, my question related to the section “what is not possible”: If I have a use case for this I will let you know :slight_smile:
Yours,
Felix

9

@felixhelix We can assume that the current proposed implementation at https://github.com/pkp/pkp-lib/issues/9434 satisfies the all the use cases, right ?

10

@touhidur As far as I can see, yes :slight_smile: