Allow checking for duplicated long URLs when creating a short URL

[jr-k]

Hello,

Actually when I'm generating a link like https://google.fr and if I'm generating this link many times I have different shorten urls.

Is there a POST parameter for the endpoint /rest/v1/short-urls, like "checkExists" to get the first shorten link if it exists ?

Thanks.

---

As decided in this issue's conversation, the feature will be implemented following these approaches for every use case:

When providing this new flag:

• Only long URL is provided:
  • Return existing short URL (if more than one is found, return the newest)
• Long URL and other params are provided:
  • Check all the params in order to decide if the same short URL should be returned or create a new one
• Long URL and custom slug are provided:
  • Return existing short URL for that long URL and slug pair, fail if the slug is in use for a different long URL or create a new one if the long URL exists but with a different slug/short-code
• Long URL, custom slug and other params are provided:
  • Check all the params in order to decide if the same short URL should be returned or create a new one. If the slug is in use for a different long URL, an error will be returned.

[acelaya]

That used to be the default behavior, and it was changed at some point, since users wanted to be able to get different short links to the same destination (to compare the most successful options).

Also, since there are several metadata for a link (slug, visits limit, dates...), there are more checks than just see if the long URL is used, in order to find out if the user is duplicating data.

That said, I think it is a reasonable feature, so I will try to provide a nice and consistent way to be able to avoid new short URLs to be created for the same long URL.

I also had in mind allowing to "merge" already created short URLs, as long as they have the same short URL.

[jr-k]

Ok in many shorten-url services the default behavior is to have 1-1.

I'll be pleased if you can provide an easy boolean switch 1-1/1-N.

Very nice product by the way, thanks !

[acelaya]

Thanks :)

[acelaya]

Hey @jr-k, I have started defining all the use cases for this feature, and I would appreciate your feedback.

This list defines all the combinations that could happen when the new flag is provided, and how I plan to make shlink behave.

Considerations:

• The cases where there's more than one option mean that I have not decided yet how to proceed :)
• The first use case has also an edge case referenced at the bottom.
• When I say other params, I mean params like validSince, validUntil and/or maxVisits.

When providing this new flag:

• Only long URL is provided
  • Return existing short URL (1)
• Long URL and other params are provided
  • Ignore new flag and behave as before
  • Check all the params in order to decide if the same short URL should be returned or create a new one
• Long URL and custom slug are provided
  • Return existing short URL for that long URL and slug pair, fail if the slug is in use for a different long URL or create a new one if the long URL exists but with a different slug/short-code
• Long URL, custom slug and other params are provided
  • Ignore new flag and behave as before
  • Check all the params in order to decide if the same short URL should be returned or create a new one. If the slug is in use for a different long URL, and error would be returned.

Edge cases:

1. What if more than one short URL is found for provided long URL?

[jr-k]

Seems nice ! Happy to hear that you're actively working on this.

Well, all these cases seems ok to me. For the edge case two possiblities :

• Forbid url generation when multiple urls match a short one
• Return the oldest or newest

Do you see any other ways ?

[acelaya]

I will probably return the newest one for now, and consider adding a breaking change and return a list in the next major release of the API.

As for points 2 and 4, I wanted to know your opinion on which of the two proposed approaches should be implemented.

Probably the more correct one is the second in both cases, but it might be counter intuitive.

For example, if 10 months ago you created a short URL for https://google.com with no other params and now you try to create a new one for the same long URL, selecting the new flag, and providing a validSince=2019-01-20.

Would you expect the system to create a new short URL for the same long URL but with the date limit, or to get the old one which has no validSince?

Another option would be to update the old one and return it, but I think it is counter intuitive too. What sense would it make to add a validSince to an old short URL which has already received visits and is probably posted somewhere and will suddenly stop working until the date is reached. I certenly would not expect this behavior, so I would choose among the other two.

[jr-k]

Oh yes sorry I missed these points. Yeah, 2nd options are the smartest way to do that I think.

For your next question I would expect that the system return the old one with no validSince.

To be honest I'm not using all these features about stats on custom links and so on, I don't really know what are the best choices for all these questions. I'm just using it in a very simple way, a unique 1-1 short-long url match service.

[acelaya]

Yes, I also think that's the best approach. Other options introduce unintended side effects.

Also probably most of the users are almost never using those params, the same as you, so it will be the best way to go in most of the cases.

Thanks a lot for your feedback. I will be working on this feature next in order to include it on next release.

[acelaya]

@jr-k I have just merged the pull request implementing this feature. I'm not sure when will I release v1.16, but this feature will be included :)

I will also implement the feature in the web-client, but if you are using any custom implementation, you will be able to use this as soon as shlink v1.16 is released.

[jr-k]

thanks this is awesome !

[acelaya]

Hey @jr-k I have just released Shlink 1.16, which includes this feature https://github.com/shlinkio/shlink/releases

I will soon add support for it in shlink-web-client. Maybe you want to watch this issue: shlinkio/shlink-web-client#101

[acelaya]

@jr-k I have just merged the task implementing a new checkbox enabling this feature in shlink-web-client.

The feature will be part of v2.1.0. I hope to get it ready as soon as possible, but I'm affraid it will probable take some days.

I'll let you know when it is deployed.