Differences

This shows you the differences between two versions of the page.

--- url-shortener [2018/08/24 05:26]
111.125.228.126 [Login]
+++ url-shortener [2018/08/24 07:10] (current)
111.125.228.126 [What is not included]
@@ Line 1: / Line 1: @@
-====== URL shortener service ======
+===== URL shortener service use cases =====
 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.
-===== Shortening a HTTP/HTTPS URL =====
+==== Shortening a HTTP/HTTPS URL ====
   - The web app submits a HTTP URL to the web service.
@@ Line 15: / Line 15: @@
     - The shortened URL.
-===== Creating a shortened URL based on user's entry =====
+==== Creating a shortened URL based on user's entry ====
   - 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.
@@ Line 29: / Line 29: @@
-===== Updating a shortened URL =====
+==== Updating a shortened URL ====
   - 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.
@@ Line 46: / Line 46: @@
       - the short URL, which remains unchanged despite the updation
-===== User sign up =====
+==== User sign up ====
   - The web app submits the email address and password of the new user.
@@ Line 54: / Line 54: @@
   - 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.
-===== Confirm email =====
+==== Confirm email ====
   - The user clicks on the verification link inside the confirmation email.
   - The server validates the code inside the verification link.
   - If the code is valid, then the user's status is moved from 'provisional' to 'confirmed'.
-  - The server returns success and redirects the user to the login page.
+  - The server returns success and redirects the user to the subscription plans page.
-===== Login =====
+==== Subscription to a plan ====
+  - The plans page on the web app requests the server to return the list of plans.
+  - The server returns the following details about the plans.
+    - Name of the plan
+    - Price of the plan per month
+    - Bulk price of the plan per year
+  - The web app chooses one of the plans.
+    - If the plan has no price, then the server redirects the browser to a welcome page, which has a link to the login page.
+  - If the plan has a price, then the server redirects the browser to a payment gateway.
+  - The user completes the payment. The payment gateway calls a landing page on the server.
+  - The landing page on the server confirms that the payment was made.
+     - If the payment is successful
+       - The landing page redirects the browser to a welcome page that has the link to the login page.
+       - An email is sent to the user, confirming the payment and with a link to the login page.
+       - The user's status goes from 'confirmed' to 'active'.
+     - 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.
+     - If the payment failed or was rejected,
+       - 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.
+       - A payment failure email is sent to the user and it has a link to the plans page.
+==== Login ====
   - The web app submits the email and password to log in.
@@ Line 68: / Line 89: @@
   - 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.
-===== Get a list of previously created URLs =====
+==== Get a list of previously created URLs ====
 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.
@@ Line 81: / Line 102: @@
     - Last date on which URL was modified
     - Number of times the URL was hit
+==== Go to the real URL behind a short URL ====
+  - A user clicks on a link containing the short URL.
+  - When the clicked URL is opened, the server increments its usage counter by 1.
+  - The server looks in the database for the real URL behind the short URL.
+  - The server redirects the user to the real URL.
+==== Create a short URL which is user-specified or has a prefix/suffix ====
+  - The web app submits all the info similar to the 'URL shortening' use case, but also submits the following info.
+    - A specific word to be used as the short URL, instead of a 6-character random generated one.
+    - A prefix to be used in front of the word.
+    - A suffix to be used behind the word.
+  - The server behaves exactly like the 'URL shortening' use case, but in the field for short URL returns the following.
+    - {prefix}-{short name}-{suffix}
+      - where prefix is submitted by the web app. If no prefix was submitted, then the section {prefix}- is removed.
+      - suffix is submitted by the web app. If not submitted, then the section -{suffix} is removed.
+      - short name is either submitted by the web app or is a 6-character randomly generated string.
+===== Server-side responsibilities =====
+==== Maintenance of short URLs and the associated real URLs ====
+The server shall maintain the following data for URLs
+  - Short URL, containing the
+    - prefix
+    - suffix
+    - a user-specified short name or a 6-character alphanumeric random string with number, capital letters an small letters
+  - The real HTTP URL
+  - The iOS URL if there is an app that can deep link to the content corresponding to the HTTP URL
+  - The Android URL if there is an app that can deep link to the content corresponding to the HTTP URL
+  - The number of hits to the short URL
+==== Detecting the iOS and Android deep-link URLs behind HTTP URLs ====
+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.
+==== User accounts ====
+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.
+  - Email address
+  - Name
+  - Plan subscribed to by the user
+  - Status of the user: 'provisional', 'confirmed', 'active'
+  - History of URLs shortened by the user.
+  - Current subscription plan if any
+==== Sign up ====
+  - 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.
+  - 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.
+  - An unconfirmed email will be deleted in 48 hours, so that it can be used for a new sign-up again.
+==== Subscription ====
+  - All users need to subscribe for a plan.
+  - A free plan is included with less features.
+  - A payment gateway API will be used to allow users to pay for premium subscription with all features.
+  - A landing page / callback on the server side will be used by the payment gateway to communicate with the server about payment status.
+  - The server stores the following details about a payment.
+    - Transaction ID
+    - Amount
+    - Status: pending, done, rejected, failed
+  - The server stores the following details about a user's history of subscriptions.
+    - user id
+    - plan purchased
+    - plan start date
+    - plan expiry date
+==== Login ====
+  - Logging in will be in the form OAuth authentication using 'password' grant type.
+  - 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.
+  - 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.
+==== Redirection from short URL to real URL ====
+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.
+===== What is not included =====
+  - 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.
+  - 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.
+  - Payment gateway merchant account also needs to come from the owner.

DokuWiki

Site Tools

Differences

Page Tools