search

dimtion / Shaarlier

Simple Android app for sharing links on Shaarli.
GNU General Public License v3.0
97 stars 11 forks source link

Access / authenticate to Shaarli via API #37

Closed MagicFab closed 4 years ago

MagicFab commented 5 years ago

Shaarli can be accessed through a REST API:

https://shaarli.github.io/api-documentation/

It would be nice to use that instead of requesting a user password when setting up Shaarlier.

dimtion commented 5 years ago

Hello MagicFab,

You are right, using the Shaarli REST API should be now the canonical way to access it. I unfortunately don't have much time to spend on Shaarlier, I barely have the time to fix the existing issues.

The support of the API should naturally come with #20.

I'll keep you in tune, but I cannot guaranty you any ETA !

Anyway, thanks for opening the issue to keep an eye on the feature.

MagicFab commented 5 years ago

No stress, take your time. If there is a way to contribute or finance this and other features, it would be nice to see how much effort, resources ($) could make this happen and suppot your work when you have time.

mro commented 5 years ago

Hi @dimtion, I'm currently slowly implementing the delicious/pinboard API. I do so on top existing shaarli installations by dropping a small additional, 0-config, binary pinboard.cgi (statically linked Go). See a demos here: https://github.com/mro/Shaarli-API-test/issues/7#issuecomment-453814817

What do you think about such a thing? I think, I will change ShaarliOS to go that way and do get/add calls when sharing links and mere get to check credentials.

dimtion commented 5 years ago

Hi @mro,

Sorry for jumping on the issue this late, having a bit of time I'm starting considering using an API for Shaarlier instead of parsing the HTML returned by the server.

If I'm reading correctly you are proposing an API following Pinboard specification, which looks more tested and complete than the one developed within the Shaarli/shaarli fork?

If that is the case, I am not sure this is the best path, in my opinion using and/or creating more tests for the defacto official Shaarli REST API would be much better bet for our projects. Also it would not need our users to drop (even a light) binary in their installation. Would it not be possible to merge that upstream?

What do you think?

mro commented 5 years ago

Hi @dimtion,

nice to hear from you, I hope you’re doing well and still have a bit of free time to spend for Shaarlier!

Am 28.03.2019 um 11:45 schrieb Loïc Carr notifications@github.com:

Sorry for jumping on the issue this late, having a bit of time I'm starting considering using an API for Shaarlier instead of parsing the HTML returned by the server.

indeed, using a stable API is the only way in the long run. Even more so considering the (Apple) App-store submission lottery where changing a semicolon can mean Apple arbitrarily forces you to change the App’s name or whatnot.

If I'm reading correctly you are proposing an API following Pinboard specification, which looks more tested and complete than the one developed within the Shaarli/shaarli fork?

Well, it’s less about completeness but more about API tests at all, project focus, NIH syndrome and culture of what I see from the shaarli project owners that made me turn away from Shaarli/shaarli. And it’s not that I propose anything, I just do it.

I became opinionated about simplicity and want tools that are hassle-free to self-host and operate. I pushed that with my experiment https://mro.name/shaarligo/slides and am quite pleased where it’s heading. And meanwhile, I even avoid PHP altogether and rather look at Go/Rust/OCaml.

If that is the case, I am not sure this is the best path, in my opinion using and/or creating more tests for the defacto official Shaarli REST API would be much better bet for our projects.

I for my part have done enough HTTP tests for shaarli for a lifetime. https://github.com/shaarli/Shaarli/pull/536#issuecomment-220130830 I find the pinboard API quite a good bet. Maybe there’s better clients than mine out there and my users will migrate. I’m fine with that. And have choice of clients myself.

Also I consider interoperability beneficial. I’m glad I didn’t waste any time on the shaarli API. I may add an enclosure extension to ShaarliOS based on ShaarliGo and reverse comments via webmentions or such. And POSSE to pinboard and twitter maybe. I can’t imagine doing any of this under oversight of the shaarli project owners.

Also it would not need our users to drop (even a light) binary in their installation.

Indeed, there may be different opinions about that, but to me that makes sense.

Would it not be possible to merge that upstream?

I can’t imagine. I consider the shaarli API miserably and utterly failed and it is so for a reason. It was invented ignorant the prior art that IMO fully does the job. Where do you want to go from there?

What do you think?

Do you know the talk „the website obesity crisis“ or the essay „a plea for lean software“?

I think for self-hosting one should prefer 0-dependency, statically linked binaries, few features, simple persistence and ideally no server-side code for visitors.

sebsauvage/shaarli was inspiring, elegant and cute. I’m extremely grateful it was built and consider myself lucky that I happend to find it. Shaarli/shaarli is going another route. Farewell and thank you for the ><)))°>

What do you think? M

P.S.: have you seen https://github.com/mro/Shaarli-API-test/blob/develop/openapi.yaml