This is a web service that allows the user to shorten a URL into a small string, similar to Tiny URL, bit.ly, etc. A shortened URL can be edited to change the source URL. Here are some use cases for a user who uses the web service.

1. The web app submits a HTTP URL to the web service.
2. If the service detects that the URL belongs to a well-known website that also has iOS / Android apps, then the server builds URLs with app-specific schemes that will be used for iOS and Android.
3. If the URL does not belong to any well-known website with known apps, then the server will use the same HTTP URL for iOS and Android also.
4. The server returns the following to the web app
   1. If the URL belongs to a well-known app, then which well-known app it is, e.g. facebook, amazon.
   2. The HTTP URL that was submitted by the web app.
   3. The URL that will be used by iOS. If not a well-known app, this URL is the same as the HTTP URL.
   4. The URL that will be used by Android.
   5. The shortened URL.

1. The web app submits the following details to the web service. Note that the web app can send all three or just one, if only a specific device is being targetted.
   1. HTTP URL
   2. A seperate URL for iOS.
   3. A seperate URL for Android.
2. In response, the server creates a short URL and returns the following response.
   1. The HTTP URL exactly as submitted by the web app. If this field was blank, then the it is left blank.
   2. The iOS URL as submitted by the web app.
   3. The Android URL as submitted by the web app.
   4. Shortened URL

1. The web app submits the following details to change within a URL. The web app may submit all three or just one or two of the following.
   1. the new HTTP URL
   2. the new iOS URL
   3. the new Android URL
2. One of the following happens at the server.
   1. If the web app submitted only the HTTP URL, then the server detects if it is from a well-known website.
      1. If a well-known website with an app, an app-specific iOS and Android URL are generated.
      2. If not a well-known website, then the HTTP URL is used for iOS and Android.
   2. Along with the HTTP URL, if the web app also submits iOS or Android URL manually, then the server does not detect an app-specific URL for that OS. It will stick with what the web app has submitted.
   3. After saving the changes to the shortened URL, the server returns the following to the web app.
      1. the latest HTTP URL
      2. the latest iOS URL: either same as what web app submitted or otherwise auto-detected
      3. the latest Android URL: either same as what web app submitted or otherwise auto-detected
      4. the short URL, which remains unchanged despite the updation

1. The web app submits the email address and password of the new user.
2. The server creates a new record in its database, but keeps the user as 'provisional'.
3. The server generates a confirmation code for the email.
4. The server sends an email to the address of the user for verification. This mail contains a link with the verification code. <br/>Please note that the user cannot start using the service before email confirmation. Otherwise, it becomes easy for a robot service to create thousands or lakhs of users at a time and abuse our service.
5. The server replies with a success code to the web app, which shows a message to the user prompting him/her to check his/her email and confirm by clicking on the confirmation link.

1. The user clicks on the verification link inside the confirmation email.
2. The server validates the code inside the verification link.
3. If the code is valid, then the user's status is moved from 'provisional' to 'confirmed'.
4. The server returns success and redirects the user to the subscription plans page.

1. The plans page on the web app requests the server to return the list of plans.
2. The server returns the following details about the plans.
   1. Name of the plan
   2. Price of the plan per month
   3. Bulk price of the plan per year
3. The web app chooses one of the plans.
   1. If the plan has no price, then the server redirects the browser to a welcome page, which has a link to the login page.
   2. If the plan has a price, then the server redirects the browser to a payment gateway.
   3. The user completes the payment. The payment gateway calls a landing page on the server.
   4. The landing page on the server confirms that the payment was made.
      1. If the payment is successful
         1. The landing page redirects the browser to a welcome page that has the link to the login page.
         2. An email is sent to the user, confirming the payment and with a link to the login page.
         3. The user's status goes from 'confirmed' to 'active'.
      2. If the payment is still in pending state when the payment gateway calls the landing page, then the landing page redirects the user to a page where he/she is told that the payment is still happening and that he/she should check the email for payment confirmation and use the login link in that email.
      3. If the payment failed or was rejected, then the landing page takes the user to a regret page and asks him/her to try again. A link to the plans page is inside this page.
      4. A payment failure email is sent to the user and it has a link to the plans page.

1. The web app submits the email and password to log in.
2. The server verifies the input and generates an OAuth token for the web app to use for all further requests.
3. The server returns the token to the web app, which saves it in local storage.
4. The web app does not have to use the login page again, as long as it holds onto the token and the token hasn't expired.

A user with an account with the service can see the list of all URLs he/she created and can modify the real URLs against each short URL.

1. The web app requests for a list of all links created by the logged in user. The OAuth token is used to represent the logged in user.
2. The server returns the following info about all the links created.
   1. Short URL
   2. HTTP URL
   3. iOS URL
   4. Android URL
   5. Date on which URL was created
   6. Last date on which URL was modified
   7. Number of times the URL was hit

1. A user clicks on a link containing the short URL.
2. When the clicked URL is opened, the server increments its usage counter by 1.
3. The server looks in the database for the real URL behind the short URL.
4. The server redirects the user to the real URL.

1. The web app submits all the info similar to the 'URL shortening' use case, but also submits the following info.
   1. A specific word to be used as the short URL, instead of a 6-character random generated one.
   2. A prefix to be used in front of the word.
   3. A suffix to be used behind the word.
2. The server behaves exactly like the 'URL shortening' use case, but in the field for short URL returns the following.
   1. {prefix}-{short name}-{suffix}
      1. where prefix is submitted by the web app. If no prefix was submitted, then the section {prefix}- is removed.
      2. suffix is submitted by the web app. If not submitted, then the section -{suffix} is removed.
      3. short name is either submitted by the web app or is a 6-character randomly generated string.