Closed vitkabele closed 3 years ago
Hello,
I'm rewriting the back-end right now, and this something to consider. I try to come up with a better API for the v2 however there are yet a lot of features to be implemented and I don't see if all of these URL shorteners can find a common ground there.
@poeti8 Is there any route to validate an API key? For the extension refactor,
I looked through the source code and couldn't find any reference in the v2 api routes
@abhijithvijayan You can call GET /users
, if response was successful then API key is correct, and if it was 401 then API key is invalid.
Large commitment and out of scope; closing given there's been no discussion, but if you feel strongly about this, I'd suggest opening a new issue with a proposed specification, and also reach out to other URL shortener projects regarding the same.
Hi!
This issue is more a enhancement idea than a bug report. Recently I decided to deploy a custom URL shortener to my beloved home server. I had an idea of how URL shortener should work and so I started to crawl around the web and search for the best choice.
It didn't take a long time and I knew that there is quite a lot of implementations available. From small scripts to more complex solutions like your's and the Polr project and to be honest, all of them do offer very similar features since there is not a very much space for new features in URL shortener.
Seeing this I said: "Well, I'll choose the one with API and an iOS application". But guess what happened? Almost every implementation offers it's own API, some of them provide even the browser extension, but there is no iOS app for none of them. Full of holiday enthusiasm I decided to write one. I compared some of the provided APIs and (not surprisingly) I found them to provide the same endpoints with the same features, but... still different enough to not wrap them all in one application.
And that's my point. Imagine some of the major open source URL shorteners using the same API, all sharing the same client applications and browser extensions. Isn't that a dream of every OSS developer? Since Your's API seems to be most complex one (Polr project has also good one, but their's lack the endpoint to list all shortened links and it seems to be unmaintained in this moment) I suggest you to create new project called kutt-api with just a formal specification of API, versioned separately from the main project. This would allow developing client apps more easily and and build them against the specific release of the API and --- hopefully, in the future some other shortener can adopt your API and profit from this beautiful feature of open source.
P.S. I didn't believe that this is possible, but then someone recommended me the tt-rss project and I saw that readers use some kind of common api called Fever API.