Differences

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

--- url-shortener [2018/08/24 06:12]
111.125.228.126 [Subscription to a plan]
+++ url-shortener [2018/08/24 07:10] (current)
111.125.228.126 [What is not included]
@@ Line 1: / Line 1: @@
-====== URL shortener service use cases ======
+===== 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.
@@ Line 61: / Line 61: @@
   - The server returns success and redirects the user to the subscription plans page.
-===== Subscription to a plan =====
+==== Subscription to a plan ====
   - The plans page on the web app requests the server to return the list of plans.
@@ Line 82: / Line 82: @@
        - A payment failure email is sent to the user and it has a link to the plans page.
-===== Login =====
+==== Login ====
   - The web app submits the email and password to log in.
@@ Line 89: / 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 103: / Line 103: @@
     - Number of times the URL was hit
-===== Go to the real URL behind a short URL =====
+==== Go to the real URL behind a short URL ====
   - A user clicks on a link containing the short URL.
@@ Line 110: / Line 110: @@
   - The server redirects the user to the real URL.
-===== Create a short URL which is user-specified or has a prefix/suffix =====
+==== 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.
@@ Line 121: / Line 121: @@
       - 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