REST API - API first approach - SQL-Ledger Development Support

Hi Armaghan,

There are many challenges when it comes to maintaining and consuming the REST API.

Channagles:
- versioning
- compatibility
- documentation
- etc

Bz using Open API 3.x standard we would be able to address majority of those challenges. Would it be possible in perl to generate those API specifications?

All the best,
Viktor

Hi Viktor,

I don't see any possibility of auto generated OpenAPI specs from code. We will need to write all the specifications by hand.

To make it easy we can do it in a collaborative way. You make the first cut of json schema, api paths etc. and then I explain the tricky points which you need to know from database design to complete the specifications.

Regards

Hi Viktor,

On today's call with Sebastian, we discussed following points:

1. To speed up our development, we will start with API I have already written. It just needs testing and an authentication mechanism.

2. We will use key based authentication; same way you are doing with existing runmyaccounts API.

I now just need to know how you generate/store api key for your existing api so that I shall retrieve the same and use it for my api authentication.

These steps can be done quickly make us productive with api in a week.

Regards

Hi Armaghan

I now just need to know how you generate/store api key for your existing api so that I shall retrieve the same and use it for my api authentication.

I'm not sure if I understand your question correctly. Do you mean with "existing api" our existing calls to SQL-Ledger?

Currently we use direct DB access and HTTP calls to get data from SQL-Ledger. For the HTTP calls we pass the ledger user as the "login" request param for authentication.

Does this answer your question?

Best regards,
Severin

Hi Severin,

I am asking how you generate and store API KEY. This is 'api_key' in url or X-RMA-KEY in header in API call.

Have a look at this screen shot too.

[image]

Hey Armaghan

This is the old portal API that we don't use/support it anymore. It is still in use for some things, but generaly its legacy code.

Can you build your api in a way that a ledger user can be used to authenticate?

Best regards,
Severin

Hey Armaghan

Just talked to Sebastian. Let me know if I can assist you in anyway to build the authentication.

Best regards,
Severin

Hi Severin,

I think per database api is ok instead of per-user authentication.

My recommendation is to store it in defaults table in database and then simply match it with the api key sent in the api request.

This apikey can be generated and stored in the defaults table by user by clicking some button like 'Add / Update key' button on defaults screen.

md5_base64 hash of database name contcateted with current time is a good idea to generate a key or something else like mentioned on this page: https://stackoverflow.com/questions/2468012/how-can-i-generate-a-unique-id-using-a-hash...

Is that ok?

Regards

Hey Armaghan!

Since the authentication is a core part of the API, I think we should really invest in getting it right from the beginning.

I agree that we can go with a token-based authentication. However I suggest to do it user based and short lived (like we do it in our new portal)

What do I mean by that?
https://www.baeldung.com/cs/tokens-vs-sessions#token-based-authentication

Currently we access SQL-Ledger with username and password. It would be awesome if you could provide an endpoint that authenticates the user using those credentials and then provides a token that is valid for x amount of time.

This token can then be used to authenticate against your API (of course checking if the user has access to the used client/db)

The validity of this token gets refreshed (keep alive) on each request and expires after x amount of time of users inactivity.

This will significantly increase the security of the system, by for example greatly limiting the risk of leaked tokens. Security is a major concern for me here because we directly access sensitve customer data.

Let me know what you think.

I wish you a nice weekend!

Best regards,
Severin

Have you looked into:
https://github.com/OpenAPITools/openapi-generator/blob/master/docs/generators/perl.md

Yes, I am familiar with OpenAPI generators including this one but I have not used so far.

But to use these generators we need to first build OpenAPI specs which includes not only API end points but also JSON schema for our entities (invoices, orders, gl, vendors, customers etc.)

If there is no hurry, we can go to this route.

If we need something ready today then existing API is ready and can be implemented after your testing. I just need to add authentication to it.

Regards

RSS Feed of thread