Allow choosing custom slugs when shortening a new URL

[tylerhall]

No description provided.

[MasterOfTheTiger]

This needs more design discussion. What would the URL be for someone to add a custom slug for a URL? Should it be some GET information?

[tylerhall]

I would like to stick with making it GET accessible since that's how all the other script parameters are made available.

I realize it might get (is getting?) kinda silly if we keep stuffing configuration options into the URL, but that was my design goal with this script from the beginning. It's called simple-url-shortener because I want it to be as, well, simple, as possible.

Sure, we might eventually want to let the script accept JSON via POST or something to allow advanced customization, but with the basic stuff available as part of the URL, I'm at least able to integrate it extremely quickly into other scripts/automations such as bookmarklets, iOS Shortcuts.app shortcuts, shell commands, etc.

Anyway, with those design thoughts out of the way...

The current URL syntax to shorten a link is:

https://example.com/http://domain,com

And for password protecting a new link...

http://example.com/your-password/http://domain.com

In hindsight, I think specifying the slug where the password currently is might have made more sense. So, something like...

http://example.com/custom-slug/http://domain.com

And then if you wanted a custom slug and password, it could be extended to...

http://example.com/custom-slug/your-password/http://domain.com

That makes sense to me, especially since it's probably more likely that someone would want to specify a slug vs create a password. (Is that a wrong assumption?) So I like having the slug be the primary (first) parameter.

But then what if someone wants a password but without a custom slug? I'm not sure how to handle that.

The problem with my custom slug URL suggestions above is that they will break compatibility with the script as it currently is since the password parameter comes first currently. Personally, that doesn't bother me given that this project is all of six months old and there's probably eight people actually using it. I figure define the feature set and make breaking changes early in a project's lifetime and then announce a stable API when it's...stable.

Thoughts?

[MasterOfTheTiger]

My thought is that it is probably better to accept normal GET requests. Such as this: http://example.com/?url=https://https://github.com/tylerhall/simple-url-shortener/&slug=url-shortener&password=totallysecurepassword.

That way order does not matter at all and more features can easily be added. The way you did it always seemed a little confusing to me, but I understand your desire for simplicity.

[tylerhall]

You're probably right. It will get unwieldy over time.

I'm fine with switching to real GET query string parameters.

Would url= require the user to percent encode the passed in URL? I'm thinking about if they want to shorten non-clean URLs that have & or ? in them?

[MasterOfTheTiger]

Good question. I will figure it out, but first, I have an important question:

How should this be implemented. I can think of two options:

http://example.com/create?, http://example.com/stats?, etc, then parameters; or,
http://example.com/?type=create& then parameters.

The former would be cleaner, so I believe that is the way to go. But there is the quesiton of how exactly it should be broken up.

The exact endpoints should be established before proceeding.

[tylerhall]

I like

http://example.com/create?

and

http://example.com/stats?

[MasterOfTheTiger]

I will implement this through the next few days. I think I should make it backwards compatable. It does not seem to be so hard to do that. But then again, it may make the code a little too complex than it needs to be for something that has only "eight people using it".

[tylerhall]

Yeah, I would just go ahead and make it break compatibility. Folks can stabilize around the new API going forward.

Thanks for working on this!

[MasterOfTheTiger]

I am having great progress on this, but I have another question. Should the stats page use normal GET requests or should it stay as it is already? Is there any more information you may want to pass onto that page in the future?

[MasterOfTheTiger]

Another problem I am trying to work around is with URLs which include &, because they interfere with what GET uses.

I could make it so that it detects when there are perameters which create does not suport, and puts it into the url variable instead. That may work, as long as the program's GET variables are different enough from common ones.

[MasterOfTheTiger]

I am having great progress on this, but I have another question. Should the stats page use normal GET requests or should it stay as it is already? Is there any more information you may want to pass onto that page in the future?

I figure that it is a good idea to do use GET requests here. I forgot about password protections. So I will proceed with this part.