LimeSurvey have SOAP before, not in last release
Current it's XML-RPC/JSON-RPC

You can make a new API via plugin if needed , see example here : https://gitlab.com/SondagesPro/redoSoapServer

Think we must close this feature request (or create a new "Plugin creation request").

Will this feature get merged if I start working on it?

Why ?
Create a plugin : no need to be merged.

Because we are going to make an Android application, and REST API is needed. You know how widely REST API is used, to the point LimeStore has one. Could you please tell me why you are against having a REST API? Maybe because LimeSurvey already has an RPC API, or it would have maintenance cost?

In the case of the transition, we can simply call the REST API internally from the RPC procedures, so adding a new RPC procedure would have little cost.

Also, in https://manual.limesurvey.org/Plugins_-_advanced , it is recommended that we should not use internal classes in our plugins.

Could you please tell me why you are against having a REST API?

I'm not against a REST API (i don't really care).
I'm against adding new feature to maintain by core developer when we already have a lot of issue not fixed.

the point LimeStore has one.

Currently yes, but it must come back. And if you want : you can improve it to allow more plugin update system … for example : allow to have different URL for limestore.

Alright. So I'm going to create a plugin for that. Should I create a Plugin-category issue, or that relates to core plugins?

Remind : i'm an external dev … i give my opinion. Not LimeSurvey all dev decision here …

It seems this issue doesn't get attention from the internals, so that's completely OK. :)

So you have experience with plugin development... What do you think about my last question?

I don't have answers :)

Can try : https://forums.limesurvey.org/forum/news/122416-discord-channel-for-limesurvey-community
But remind : it's holiday time.

OK. Thanks for you help!

We want to develop a REST API ourselves. It's in our pipeline. Nothing stops you from making your own plugin API, of course.

Then can be included in core plugins after @ollehar ?

Probably not, since we will be using Yii 3 for our approach.

? Using Yii 3 disable plugins system ?

@ollehar , so may I contribute to the progress you're making, instead of working on a separate plugin, if it's going to be made in the open, to prevent duplicating the effort?

@machitgarha, maybe, when we have the basic architecture up and running. Do you know Yii 3 anything?

No. But that should not matter, as having a REST API is a must in our side, I would have to start learning it.

How much would it take to reach the basic architecture? Asking because we have a deadline for our development, and I want to have the REST API as soon as possible.

Can't I participate in the warming-up process itself? I mean, is it an internal or restricted process?

ASAP : the only way is plugin …

In the case of a plugin, if I start developing it using Yii 2 (maybe using some of Yii 3 patterns for easier transition), would it be a chance for my plugin to be moved into the core (maybe using yii2-openapi package)?

Yii 3 is not released yet, and maybe not anytime soon, so basing my plugin on it is not a good idea.

The design of the API base is internal for now, but maybe we could open it up. But it's based on Yii 3 inside Yii 1.

You'd have to use Yii 1 for your plugin, since that's what LS is using right now.

@machitgarha What's your use-case for the Android app? What API calls would it need?

@ollehar, the app's going to be an LS client, providing most of the LS's main functionality. So, we basically want a feature-full API.

BTW, I would use Yii 2 for my plugin, although I know LS is written in Yii 1. The reasons are, the tools available, maybe increasing the chance of forward-compatibility of my API in the case of LS transition, and the chance of inclusion in the LS core. By the latter case, I mean if you publish the Yii3-based API, there might be some missing features that I've implemented.

You're talking about the admin interface? Creating surveys etc?

The most simple API imaginable is to have a POST, GET, PATCH etc for each active record model in the application/models/ folder, but then you need more logic in your app to make sure the data stored is consistent/not broken. The validation inside the active record class will help you some, but not all the way. Such an API can probably be implemented in a couple of hours.

LS might never get ported to Yii 2, but rather from Yii 1 to Yii 3 instead.

@ollehar, yes

I would still use Yii 2 for the plugin, as I don't have hope for Yii 3 to be released anytime soon.

BTW, thanks for your help.

I don't think anyone ever made an LS plugin in Yii 2... You'd have to bootstrap Yii 2 inside your plugin, after Yii 1 is already started. It's not impossible, but I don't know if it's easy. I'd recommend Yii 1, for less headache.

@ollehar, thanks for your recommendation. I'll look into it.

Quick and dirty-ish example here: https://github.com/olleharstedt/LimeSurveyRestAPIPlugin

License is GPL2.

Quick and dirty-ish example here: https://github.com/olleharstedt/LimeSurveyRestAPIPlugin

?
$this->subscribe('newDirectRequest');
You need to subscribe to https://manual.limesurvey.org/NewUnsecureRequest for $_POST (and maybe other) , no ?

You need to subscribe to https://manual.limesurvey.org/NewUnsecureRequest for $_POST (and maybe other) , no ?

Yes, maybe. :)

But actually, I'm not sure if this is a good approach... Perhaps it exposes too much of the internal database structure by mapping to active record classes directly instead of to "domain elements". Maybe it would be better to REST-ify the older remote api instead. :d

Also, it's not really REST if you can't authenticate using the API. Permission checks assume a PHP session is established using admin login or such. Maybe that can be fixed.

I mean for evolution :)

Currently not needed …

@ollehar, thanks for the prototype. Currently, I subscribed to beforeControllerAction event. Not sure which one is actually better.

Yeah, that'd work too. You can do it without event if you use plugin/ajax controller action, but then it assumes a login session, and will redirect if you're not logged in. Which is probably not what you want for an API.

With beforeControllerAction : i replace default remotecontrol for specific function (when user can not update the link, use different link for each call) https://gitlab.com/SondagesPro/Authentification/AuthRemoteToken/-/blob/main/AuthRemoteToken.php#L559

But here : i think https://manual.limesurvey.org/NewUnsecureRequest can do the job. Just a different link :)

@DenisChenu, really thanks for the help. It seems beforeControllerAction only listens for GET requests, which isn't suitable for a REST API. Going to subscribe to newUnsecureRequest. :)

Oops, hell no. beforeControllerAction works great, my bad. Didn't know calling App()->end() is necessary for the PluginBase::log() to work, specially when the request is non-GET. :)

beforeControllerAction only listens for GET requests

No : beforeControllerAction happen for ALL LimeSurvey (code) request :)
(no css/js/png or direct PHP link)

You find yourself.

Didn't know calling App()->end()

$event->set('run', false); must work too .

Possible output
run as boolean, if false : the controller/action are not called. LimeSUrvey do nothing. Then you can do your own page/system to replace any action.

$event->set('run', false); must work too.

I did that. The problem was something else. Thanks for the help!

You need to consider how to do authentication too. That's supported in the old RPC, but not in my trashy prototype. That's why I started refactor the old RPC a little, to see if it's possible to put a RESTy facade in front of it.

Hello. I've built a LimeSurvey plugin providing a RESTful API. It's not complete yet, but provide the main functionality for sending responses. Here it is: https://github.com/machitgarha/limesurvey-rest-api/

I'll be happy if you - anyone who is reading - send feedback like opening issues, or contribute in the project.

Thanks to Mr. Denis Chenu and Mr. Ollehar for their helpful comments and code.

P.S: Sorry for saying we want a feature-full API. I was wrong; it was not the case. :)

Nice. We've been working on a core REST API too, last weeks. It will be in dev branch, soon-ish.

Great! I hope my plugin to be helpful for some, at least until the core REST API arrives... Keep up the good work. :)

And thanks for giving a star. :)