search

uyuni-project / poc-uyuni-api

[Proof-of-Concept] Uyuni API Gateway. Provide REST-like API over XML-RPC
MIT License
0 stars 1 forks source link

Add support for overloaded functions (REST) #1

Open isbm opened 4 years ago

isbm commented 4 years ago

Overloaded XML-RPC functions won't go right over REST interface, because signature detection is simply not yet implemented at call event. Currently arguments are passed "as is" and it works as "first wins". This may result to incorrect handling XML-RPC endpoints, such as channel.software.getDetails or channel.software.setDetails etc.

To add overloaded function support, following should be done:

  1. Reconcile input types
  2. Match them with the generated spec
  3. Update swagger definition

@paususe @admd @chiaradiamarcelo @joesusecom

chiaradiamarcelo commented 4 years ago

What I don't understand is what are we aiming for here. Our API won't be RESTful just with this, if we are going this direction and we want to be "RESTful" we really need to start thinking about changing the API signatures

isbm commented 4 years ago

@chiaradiamarcelo Sure thing! But also you should not go rampage like to fix all at once. :wink: The API are in use everywhere and you should do it step-by-step, providing a very clear migration plan (or best, do it transparently with each release, keeping backward compatibility). Currently REST layer supports only POST method, because the way XML-RPC are designed for Uyuni at first place. Surely to implement also GET/PUT/DELETE you first need to know where they are applicable and generate specs accordingly. For example, you can GET everything that starts with get.... and list.... At least current XML-RPC APIs has a good conventions.

Another way to fix this would be to cleanup XML-RPC doc macroses through all of the Java code (currently they are very messy and broken, hence I abandoned the idea to generate specs from that). But if you clean that up, add some linter on it and prevent broken XML-RPC doc being committed, then there you could also set flag which method REST should be built for. That is also longer path, but will result to a proper XML-RPC documentation, once for all.

The aim of REST layer is to provide a single interface to those, who wants to call Uyuni API as well as Salt's API and other possible API in one go. For that you certainly do not want to provide different connectivity layers zoo. So for example, spacecmd or other "glue tools" could have one single token to all the Uyuni cluster and call whatever they need to in a mix. So you no longer worry about transport, types, tokens, security management etc, but just connect here and call /salt/something or /uyuni/system/listSystems etc etc and mix all that in your code using e.g. requests from Python or so.

isbm commented 4 years ago

But plain XML-RPC APIs already should work out of the box as is (one to many and vice versa).