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
Ledger format API endpoint(s) #1322
Comments
In a perfect world a json format like the following or similar would be even better i think:
with posting being something like:
(Having amount being nilable would allow entering transactions that auto-balance, like in the text format) |
This sounds very sensible but also quite like what hledger-web's add form does - I don't remember all the routes involved here but can't you use the one the add form uses ?
|
Checking.. here's the routes file; /add is what the add form posts to. |
Hm, yeah but that would require getting a csrf token i think (i can't read haskell so i just checked the network tab when adding a transaction in hledger-web). There was |
Also, this returns html which is horrible to parse for any errors that might've occured. |
Ok.. we should add this. I'll coach anyone who has time to work on a PR. |
I think adding API endpoints or at least one for adding entries in the ledger text format would be very helpful. I'll try to explain why:
I'm currently writing a simplified web-frontend to use for quickly entering transactions into ledger. From the user perspective this should be as easy to use as possible. My current main grievance with the hledger-web json api is the amounts. Having to specify it using decimal mantissa, commodity formatting options etc. requires me to basically duplicate the functionality already done in hledger cli where the parsing is implemented. A quick example. I might have defined commodities like this:
1.000,00 €
and1.000,0000 "SOME ETF"
. Now when a user enters an amount to a transaction, I don't want to force any specific format on them as I can't know what they have defined (or not defined) in their journals. So what I'm left with is having to either make assumptions about the format or making it configurable in the frontend.From my naive point of view this could be avoided if the server would just check the
Content-Type
and/orAccept
header of the incoming request and use the current json format forapplication/json
(or unset for backwards compatibility) and run it through the hledger cli code when it'stext/plain
. So, and correct me if I'm wrong, I think this is fairly low hanging fruit and would help prevent duplication in frontend(s) and server.The text was updated successfully, but these errors were encountered: