SQL Ledger REST API Design - SQL-Ledger Development Support

Hi Armaghan!

I was wondering how the REST API is designed in Perl.

How SQL Ledger was structured (according to my non complete understanding):

Upon request an SQL query was formed and executed, then the result set was mapped to the HTML and rendered in the browser.

What design I imagine:
We would expect to have now the REST API between the View and controller layer

So, Upon request SQL Ledger REST API is called, then the repose of the API is mapped to the HTML and rendered in the browser.
FYI SQL query is executed inside the REST API call.

Following would provide following advantages:
- Business logic not duplicated
- Validation are not duplicated
- cleaner design

Cons:
- More work

Why that very question:
We are currently consuming the SQL Ledger resources trough HTML calls. We map the x-form request and send them. In case we would have an SQL Ledger REST API that is build on top of SQL Ledger UI (HTML) some business logic and validation would get duplicated and we could face more bugs and higher effort of maintenance.
So, it would be challenging for us to apply further changes.

Looking forward for further discussion,
Viktor

Hi Viktor,

There is an existing REST API (https://www.runmyaccounts.ch/support-artikel/run-my-accounts-restful-api/) which can be used to get and post data to sql-ledger than going through html form. Why that is not being used? Probably due to some shortcomings of that api?

I have been working on a new API with Sebastian suggestions. We can keep working on it starting with the features you need in short term and then covering other things as we go.

Also can you please let me know the front-end development technology/setup which you are using to develop user interface and consume the API for all data processing?

Regards

Hi Armaghan,

We would appreciate if you could answer the API source code design question.

I believe Sebastian is a very good person to work with as he has the best understanding what is needed by the business and his technical expertise is good enough to close the gap for development communication. I believe he is the right person to support further development of the SQL Ledger.

Regarding the client technology that we would use to consume the API.
Most probably 100% of the API would be consumed by server side code, so Java. Why? we would need to apply additional authentication and authorisation cross cutting concerns. Also we would in most cases would need to do a response post-enchantment.
In Java one could could consume anything really. We are consuming the SQL Ledger HTML responses at the moment. It is definably not the best approach adn has too many shortcomings. Perhaps could be something that would motivate us to move away fro using SQL ledger.
What we would like to do is work with standards, to avoid many issues in the future that come with manual impl. and not API first development approach.

Right now our API is ready which interactions with SQL-Ledger database through SL/* modules which ensure that database is always in a consistant state.

This API is ready to use. We can also start building OpenAPI specs if that is the desired thing right now to proceed.

I shall discuss this with Sebastian and will proceed accordingly.

Regards

RSS Feed of thread