Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

creating a web service plugin for lsc #100

Open
bilbo-the-hobbit opened this issue Nov 4, 2019 · 7 comments
Open

creating a web service plugin for lsc #100

bilbo-the-hobbit opened this issue Nov 4, 2019 · 7 comments
Assignees
Milestone

Comments

@bilbo-the-hobbit
Copy link

Hello @coudot @soisik,

we are currently thinking about using lsc for his transformation engine and synchronisation aspect in complex workflow.

The scenario is like this :

  • getting the data from a application through is webservice to lsc
  • applying transformation to it if nedeed
  • sending back the data to another webservice from lsc to provision this data

The use case if for example :

  • Application A is a student management system with all the data about the life cycle of students
  • Application B is FusionDirectory and is REST webservice
  • LSc with a webservice plugin is used to get data from A and send it to B following the task programmed

do you think its feasible and useful, we would like to have it made in a generic way and contributed back to the project of course

@rouazana
Copy link
Contributor

rouazana commented Nov 4, 2019

Hello,

This is very interesting and I'm thinking about this for some time.

The main issue is how can you configure in a usable way a generic REST LSC service?
As far as I know, the following elements need to be parametrized:

  • method (GET/POST/PUT/etc.)
  • URL (with some parameters in it where you can put a pivot or some other attribute)
  • mapping between the json and a list of attributes
  • authentication mechanism

And I don't speak about specific API which can require you to create a batch before doing any request.

Here are some sample plugins I created to access some REST API:

I really hardly see a way to define the plugins in a common way, even if I would really be happy to!

@bilbo-the-hobbit
Copy link
Author

Hello,

This is very interesting and I'm thinking about this for some time.

The main issue is how can you configure in a usable way a generic REST LSC service?
As far as I know, the following elements need to be parametrized:

* method (GET/POST/PUT/etc.)

* URL (with some parameters in it where you can put a pivot or some other attribute)

* mapping between the json and a list of attributes

* authentication mechanism

And I don't speak about specific API which can require you to create a batch before doing any request.

Here are some sample plugins I created to access some REST API:

* https://github.com/lsc-project/lsc-obm-plugin

* https://github.com/lsc-project/lsc-openpaas-plugin

* https://github.com/lsc-project/lsc-james-plugin

I really hardly see a way to define the plugins in a common way, even if I would really be happy to!

thanks for the quick response .

What we now for sure is that we will need a plugin for FusionDirectory https://rest.fusiondirectory.org/

yes i don't know how its still an open question :)

Maybe provide a skeleton to create more easily webservice plugins or provide a way to read the configuration from a yaml file if they respect the https://www.openapis.org/ standard.

i perfectly understand that all of this is a big vague right now and opened this bug for discussion

@coudot coudot added this to the 2.2 milestone Nov 7, 2019
@rouazana
Copy link
Contributor

Hi,

openpapi is very interesting and a step in the good direction.

Looking at your REST api, it seems that to be able to access some object, you first need to authenticate. Which means discovering the authentication endpoint, knowing that you must get a token from it and finally use this token in every (other) calls.

How could we describe this in a configurable way?

Regards,
Raphaël.

@MCMic
Copy link

MCMic commented Nov 27, 2019

@rouazana The openapi file specifies the following:

securitySchemes:
    session:
      type: apiKey
      name: Session-Token
      in: header

Which tells you there is an authentication method called session, which is a key sent as a header with name Session-Token.

Then you have:

security:
  - session: []

Which means all methods need the authentication method "session" unless stated otherwise.

And for a few methods like login, you have:

security: []

Which indicates these ones do not need authentication.

So for a generic plugin, you could from the openapi file know which kind of authentication is expected and which methods needs it. You will still need in the configuration the way to actually login (which endpoint, with which parameters).

@rouazana
Copy link
Contributor

Interesting, thanks.

An other point of attention is pagination. It seems to be handled in very different ways in different APIs.
For example some of them rely on the offset / limit parameters, while others apply a default pagination and return the next page in the response.

@coudot coudot modified the milestones: 2.2, Future Feb 10, 2020
@soisik soisik self-assigned this Aug 31, 2020
@soisik
Copy link
Contributor

soisik commented Aug 31, 2020

Hi,

I've created a plugin to synchronize entities from and to fusiondirectory using the REST API that will be available in Fusiondirectory 4: https://github.com/Worteks/lsc-fusiondirectory-plugin

This feature request was about a generic openapi REST plugin but Fusiondirectory REST services being quite specific (for example attributes are read/write within tabs), I don't see how it could be made generic.

I'm waiting for the approval from dev team to make it available in LSC repository.

Regards

@bilbo-the-hobbit
Copy link
Author

hello @soisik,

that great news, looking forward to test and use it

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants