re-arrang follow table content

resources/noat.cards/05 Availability patterns.md

@@ -68,4 +68,51 @@ Both masters serve reads and writes and coordinate with each other on writes. If
 ## Source(s) and further reading: replication
 
 - [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/) 
-- [Multi-master replication](https://en.wikipedia.org/wiki/Multi-master_replication) 
+- [Multi-master replication](https://en.wikipedia.org/wiki/Multi-master_replication) 
+
+
+## Availability in numbers
+
+Availability is often quantified by uptime (or downtime) as a percentage of time the service is available.  Availability is generally measured in number of 9s--a service with 99.99% availability is described as having four 9s.
+
+## 99.9% availability - three 9s
+
+| Duration            | Acceptable downtime|
+|---------------------|--------------------|
+| Downtime per year   | 8h 45min 57s       |
+| Downtime per month  | 43m 49.7s          |
+| Downtime per week   | 10m 4.8s           |
+| Downtime per day    | 1m 26.4s           |
+
+## 99.99% availability - four 9s
+
+| Duration            | Acceptable downtime|
+|---------------------|--------------------|
+| Downtime per year   | 52min 35.7s        |
+| Downtime per month  | 4m 23s             |
+| Downtime per week   | 1m 5s              |
+| Downtime per day    | 8.6s               |
+
+## Availability in parallel vs in sequence
+
+If a service consists of multiple components prone to failure, the service's overall availability depends on whether the components are in sequence or in parallel.
+
+## In sequence
+
+Overall availability decreases when two components with availability < 100% are in sequence:
+
+```
+Availability (Total) = Availability (Foo) * Availability (Bar)
+```
+
+If both `Foo` and `Bar` each had 99.9% availability, their total availability in sequence would be 99.8%.
+
+## In parallel
+
+Overall availability increases when two components with availability < 100% are in parallel:
+
+```
+Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
+```
+
+If both `Foo` and `Bar` each had 99.9% availability, their total availability in parallel would be 99.9999%.

resources/noat.cards/06 Domain name system.md

@@ -14,11 +14,15 @@ A Domain Name System (DNS) translates a domain name such as [www.example.com](ht
 
 DNS is hierarchical, with a few authoritative servers at the top level. Your router or ISP provides information about which DNS server(s) to contact when doing a lookup. Lower level DNS servers cache mappings, which could become stale due to DNS propagation delays. DNS results can also be cached by your browser or OS for a certain period of time, determined by the [time to live (TTL) ](https://en.wikipedia.org/wiki/Time_to_live) .
 
+## DNS record types 
+
 - NS record (name server)  - Specifies the DNS servers for your domain/subdomain.
 - MX record (mail exchange)  - Specifies the mail servers for accepting messages.
 - A record (address)  - Points a name to an IP address.
 - CNAME (canonical)  - Points a name to another name or `CNAME` (example.com to [www.example.com](http://www.example.com/)) or to an `A`record.
 
+## DNS traffic route methods
+
 Services such as [CloudFlare](https://www.cloudflare.com/dns/)  and [Route 53](https://aws.amazon.com/route53/)  provide managed DNS services. Some DNS services can route traffic through various methods:
 
 - [Weighted round robin](http://g33kinfo.com/info/archives/2657) 

resources/noat.cards/16-5 Representational state transfer (REST).md

@@ -0,0 +1,103 @@
++++ noatcards = True isdraft = False +++
+
+# Representational state transfer (REST)
+
+## Representational state transfer introduction
+
+REST is an architectural style enforcing a client/server model where the client acts on a set of resources managed by
+the server. The server provides a representation of resources and actions that can either manipulate or get a new
+representation of resources. All communication must be stateless and cacheable.
+
+## RESTful interface
+
+There are four qualities of a RESTful interface:
+
+- Identify resources (URI in HTTP)  - use the same URI regardless of any operation.
+- Change with representations (Verbs in HTTP)  - use verbs, headers, and body.
+- Self-descriptive error message (status response in HTTP)  - Use status codes, don't reinvent the wheel.
+- [HATEOAS](http://restcookbook.com/Basics/hateoas/)  (HTML interface for HTTP)  - your web service should be fully
+  accessible in a browser.
+
+Sample REST calls:
+
+```
+    GET /someresources/anId
+    
+    PUT /someresources/anId
+    {"anotherdata": "another value"}
+```
+
+REST is focused on exposing data. It minimizes the coupling between client/server and is often used for public HTTP
+APIs. REST uses a more generic and uniform method of exposing resources through
+URIs, [representation through headers](https://github.com/for-GET/know-your-http-well/blob/master/headers.md) , and
+actions through verbs such as GET, POST, PUT, DELETE, and PATCH. Being stateless, REST is great for horizontal scaling
+and partitioning.
+
+## Disadvantage(s) : REST
+
+- With REST being focused on exposing data, it might not be a good fit if resources are not naturally organized or
+  accessed in a simple hierarchy. For example, returning all updated records from the past hour matching a particular
+  set of events is not easily expressed as a path. With REST, it is likely to be implemented with a combination of URI
+  path, query parameters, and possibly the request body.
+- REST typically relies on a few verbs (GET, POST, PUT, DELETE, and PATCH) which sometimes doesn't fit your use case.
+  For example, moving expired documents to the archive folder might not cleanly fit within these verbs.
+
+## What is HATEOAS and why is it important for my REST API?
+--------------------------------------------------------
+
+HATEOAS stands for **Hypertext As The Engine Of Application State**. It means that hypertext should be used to find your
+way through the API. An example:
+
+```
+GET /account/12345 HTTP/1.1
+
+HTTP/1.1 200 OK
+<?xml version="1.0"?>
+<account>
+    <account_number>12345</account_number>
+    <balance currency="usd">100.00</balance>
+    <link rel="deposit" href="/account/12345/deposit" />
+    <link rel="withdraw" href="/account/12345/withdraw" />
+    <link rel="transfer" href="/account/12345/transfer" />
+    <link rel="close" href="/account/12345/close" />
+</account>
+```
+
+Apart from the fact that we have 100 dollars (US) in our account, we can see 4 options: deposit more money, withdraw
+money, transfer money to another account, or close our account. The "link"-tags allows us to find out the URLs that are
+needed for the specified actions. Now, let's suppose we didn't have 100 usd in the bank, but we actually are in the red:
+
+```
+    GET /account/12345 HTTP/1.1
+    
+    HTTP/1.1 200 OK
+    <?xml version="1.0"?>
+    <account>
+        <account_number>12345</account_number>
+        <balance currency="usd">-25.00</balance>
+        <link rel="deposit" href="/account/12345/deposit" />
+    </account>
+```
+
+Now we are 25 dollars in the red. Do you see that right now we have lost many of our options, and only depositing money
+is valid? As long as we are in the red, we cannot close our account, nor transfer or withdraw any money from the
+account. The hypertext is actually telling us what is allowed and what not: HATEOAS
+
+## RPC and REST calls comparison
+
+| Operation | RPC | REST |
+|---|---|---|
+| Signup    | **POST** /signup | **POST** /persons |
+| Resign    | **POST** /resign<br/>{<br/>"personid": "1234"<br/>} | **DELETE** /persons/1234 |
+| Read a person | **GET** /readPerson?personid=1234 | **GET** /persons/1234 |
+| Read a person’s items list | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items |
+| Add an item to a person’s items | **
+POST** /addItemToUsersItemsList<br/>{<br/>"personid": "1234";<br/>"itemid": "456"<br/>} | **
+POST** /persons/1234/items<br/>{<br/>"itemid": "456"<br/>} |
+| Update an item    | **POST** /modifyItem<br/>{<br/>"itemid": "456";<br/>"key": "value"<br/>} | **
+PUT** /items/456<br/>{<br/>"key": "value"<br/>} |
+| Delete an item | **POST** /removeItem<br/>{<br/>"itemid": "456"<br/>} | **DELETE** /items/456 |
+
+<p align="center">
+  <i><a href=https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/>Source: Do you really know why you prefer REST over RPC</a></i>
+</p>

resources/noat.cards/18 Appendix.md

@@ -1,3 +1,25 @@
+# Appendix
+
+## Powers of two table
+
+```
+Power           Exact Value         Approx Value        Bytes
+---------------------------------------------------------------
+7                             128
+8                             256
+10                           1024   1 thousand           1 KB
+16                         65,536                       64 KB
+20                      1,048,576   1 million            1 MB
+30                  1,073,741,824   1 billion            1 GB
+32                  4,294,967,296                        4 GB
+40              1,099,511,627,776   1 trillion           1 TB
+```
+
+## Source(s) and further reading
+
+- [Powers of two](https://en.wikipedia.org/wiki/Power_of_two) 
+
+
 ## Latency numbers every programmer should know
 ---
     Latency Comparison Numbers
@@ -43,4 +65,15 @@ Handy metrics based on numbers above:
 - [Latency numbers every programmer should know - 1](https://gist.github.com/jboner/2841832) 
 - [Latency numbers every programmer should know - 2](https://gist.github.com/hellerbarde/2843375) 
 - [Designs, lessons, and advice from building large distributed systems](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf) 
-- [Software Engineering Advice from Building Large-Scale Distributed Systems](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf) 
+- [Software Engineering Advice from Building Large-Scale Distributed Systems](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf) 
+
+
+## Introduction of base 62
+- Encodes to `[a-zA-Z0-9]` which works well for urls, eliminating the need for escaping special characters
+- Only one hash result for the original input and and the operation is deterministic (no randomness involved) 
+- Base 64 is another popular encoding but provides issues for urls because of the additional `+` and `/` characters
+
+## MD5
+
+- Widely used hashing function that produces a 128-bit hash value
+- Uniformly distributed

resources/noat.cards/Base 62.md

@@ -1,13 +0,0 @@
-+++
-noatcards = True
-isdraft = False
-+++
-
-
-# Base 62
----
-
-## Introduction of base 62
-- Encodes to `[a-zA-Z0-9]` which works well for urls, eliminating the need for escaping special characters
-- Only one hash result for the original input and and the operation is deterministic (no randomness involved) 
-- Base 64 is another popular encoding but provides issues for urls because of the additional `+` and `/` characters

resources/noat.cards/MD5.md

@@ -3,7 +3,3 @@ noatcards = True
 isdraft = False
 +++
 
-MD5
----
-- Widely used hashing function that produces a 128-bit hash value
-- Uniformly distributed

resources/noat.cards/Representational state transfer (REST).md

@@ -1,35 +0,0 @@
-+++
-noatcards = True
-isdraft = False
-+++
-
-# Representational state transfer (REST) 
-
-## Representational state transfer introduction 
-
-REST is an architectural style enforcing a client/server model where the client acts on a set of resources managed by the server. The server provides a representation of resources and actions that can either manipulate or get a new representation of resources. All communication must be stateless and cacheable.
-
-## RESTful interface
-
-There are four qualities of a RESTful interface:
-
-- Identify resources (URI in HTTP)  - use the same URI regardless of any operation.
-- Change with representations (Verbs in HTTP)  - use verbs, headers, and body.
-- Self-descriptive error message (status response in HTTP)  - Use status codes, don't reinvent the wheel.
-- [HATEOAS](http://restcookbook.com/Basics/hateoas/)  (HTML interface for HTTP)  - your web service should be fully accessible in a browser.
-
-Sample REST calls:
-
-```
-    GET /someresources/anId
-    
-    PUT /someresources/anId
-    {"anotherdata": "another value"}
-```
-
-REST is focused on exposing data. It minimizes the coupling between client/server and is often used for public HTTP APIs. REST uses a more generic and uniform method of exposing resources through URIs, [representation through headers](https://github.com/for-GET/know-your-http-well/blob/master/headers.md) , and actions through verbs such as GET, POST, PUT, DELETE, and PATCH. Being stateless, REST is great for horizontal scaling and partitioning.
-
-## Disadvantage(s) : REST
-
-- With REST being focused on exposing data, it might not be a good fit if resources are not naturally organized or accessed in a simple hierarchy. For example, returning all updated records from the past hour matching a particular set of events is not easily expressed as a path. With REST, it is likely to be implemented with a combination of URI path, query parameters, and possibly the request body.
-- REST typically relies on a few verbs (GET, POST, PUT, DELETE, and PATCH) which sometimes doesn't fit your use case. For example, moving expired documents to the archive folder might not cleanly fit within these verbs.