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.
4. If the plan has a price, then the server redirects the browser to a payment gateway.
5. The user completes the payment. The payment gateway calls a landing page on the server.
6. 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,
      1. 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.
      2. 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.

The server shall maintain the following data for URLs

1. Short URL, containing the
   1. prefix
   2. suffix
   3. a user-specified short name or a 6-character alphanumeric random string with number, capital letters an small letters
2. The real HTTP URL
3. The iOS URL if there is an app that can deep link to the content corresponding to the HTTP URL
4. The Android URL if there is an app that can deep link to the content corresponding to the HTTP URL
5. The number of hits to the short URL

For well-known websites with apps in iOS and/or Android, the server will attempt to create the custom schema URLs as expected by those apps. Initially, the list will support only 5-6 common apps, but later the list can be expanded as the custom schema for more apps are found and documented.

The server will maintain information about user accounts for users who sign up for the service instead of using it a la carte. Here is the information that is stored.

1. Email address
2. Name
3. Plan subscribed to by the user
4. Status of the user: 'provisional', 'confirmed', 'active'
5. History of URLs shortened by the user.
6. Current subscription plan if any

1. The server will allow a user to sign up using email only. No Facebook, Google+ single sign-on is planned in phase 1. Nor will there be mobile number with OTP method.
2. All users need to confirm by clicking on the confirmation link in their email and then subscribe to a plan. A user who hasn't confirmed will be tracked as 'provisional' and will not be allowed to use the URL shortening services.
3. An unconfirmed email will be deleted in 48 hours, so that it can be used for a new sign-up again.

1. All users need to subscribe for a plan.
2. A free plan is included with less features.
3. A payment gateway API will be used to allow users to pay for premium subscription with all features.
4. A landing page / callback on the server side will be used by the payment gateway to communicate with the server about payment status.
5. The server stores the following details about a payment.
   1. Transaction ID
   2. Amount
   3. Status: pending, done, rejected, failed
6. The server stores the following details about a user's history of subscriptions.
   1. user id
   2. plan purchased
   3. plan start date
   4. plan expiry date

1. Logging in will be in the form OAuth authentication using 'password' grant type.
2. After logging in, a token is returned to the web app. As long as the token is saved by the web app and it doesn't expire, the user doesn't need to log in again.
3. Different users can do different things based on their subscriptions plans, so the server will use OAuth scopes to authorise what a user can do.

Based on the platform detected by scanning the User Agent, the server will redirect a browser to the real HTTP URL, the iOS URL or the Android URL.

1. All the NodeJS scripts will generate ONLY JSON responses. The HTML pages will need to be developed by the HTML team and these pages will act as part of a rich-client / single-page application with AJAX calls. No HTML / CSS work will be done by NodeJS developer and no HTML will be included as part of the scripts. The NodeJS server will only help the browser redirect to already created HTML pages or serve already created HTML files as templates.
2. Since, we are using login / OAuth, all the communication will be encrypted using HTTPS. But the SSL certificate will not be purchased by the NodeJS developer. It should be done by the owner of the service.
3. Payment gateway merchant account also needs to come from the owner.