If createURL returns shortened url, how does the caller ever get url_key for deleteURL?


I’m confused by choices in the System APIs section:

createURL(api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None)

Returns: (string)
A successful insertion returns the shortened URL; otherwise, it returns an error code.

deleteURL(api_dev_key, url_key)

Where “url_key” is a string representing the shortened URL to be retrieved; a successful deletion returns ‘URL Removed’.

If createURL returns the shortened URL, how does the caller get the url_key for deleteURL? presumably GET :shortened-url causes the redirect rather than returning the new resource, so there would be no way to find the url_key based on the shortened url. Should createURL return the url key instead? Or do you mean url_key to be the shortened url itself? If so, wouldn’t that block other options for e.g. edit

Hi @Barbara

When createURL returns shortened URL, that shortened URL contains a link to the original URL, so whenever we will use that, indirectly original URL will be hit every time.

Hi @Shaheryaar_Kamal Thanks for the response! I’m not clear this answers my question though. I understand that the original URL will be stored server-side and be used to redirect a GET on the shortened url. My question is purely about the api design and the choice to return a single string described as “the shortened URL” from createURL and how the caller could get from that (their only information) to the deleteURL api’s url_key. Unless url_key in fact is the shortened url, in which case I guess the caller could GET tinyurl/urls/:url_key and the extra path segment would distinguish a GET for info from the redirection expectation. :man_shrugging: