Documentation: conform to header style

Documentation/learning/api.md

@@ -2,7 +2,7 @@
 
 NOTE: this doc is not finished!
 
-## Response Header
+## Response header
 
 All Responses from etcd API have a [response header][response_header] attached. The response header includes the metadata of the response.
 
@@ -30,7 +30,7 @@ Applications can use `Raft_Term` to detect when the cluster completes a new lead
 
 Key-Value API is used to manipulate key-value pairs stored inside etcd. The key-value API is defined as a [gRPC service][kv-service]. The Key-Value pair is defined as structured data in [protobuf format][kv-proto].
 
-### Key-Value Pair
+### Key-Value pair
 
 A key-value pair is the smallest unit that the key-value API can manipulate. Each key-value pair has a number of fields:
 
@@ -54,4 +54,4 @@ message KeyValue {
 
 [kv-proto]: https://github.com/coreos/etcd/blob/master/mvcc/mvccpb/kv.proto
 [kv-service]: https://github.com/coreos/etcd/blob/master/etcdserver/etcdserverpb/rpc.proto
-[response_header]: https://github.com/coreos/etcd/blob/master/etcdserver/etcdserverpb/rpc.proto
+[response_header]: https://github.com/coreos/etcd/blob/master/etcdserver/etcdserverpb/rpc.proto

Documentation/learning/api_guarantees.md

@@ -1,4 +1,4 @@
-# KV API Guarantees
+# KV API guarantees
 
 etcd is a consistent and durable key value store with mini-transaction(TODO: link to txn doc when we have it) support. The key value store is exposed through the KV APIs. etcd tries to ensure the strongest consistency and durability guarantees for a distributed system. This specification enumerates the KV API guarantees made by etcd.
 
@@ -13,17 +13,17 @@ etcd is a consistent and durable key value store with mini-transaction(TODO: lin
 * Combination (read-modify-write) APIs
     * txn
 
-### etcd Specific Definitions
+### etcd specific definitions
 
-#### operation completed
+#### Operation completed
 
 An etcd operation is considered complete when it is committed through consensus, and therefore “executed” -- permanently stored -- by the etcd storage engine. The client knows an operation is completed when it receives a response from the etcd server. Note that the client may be uncertain about the status of an operation if it times out, or there is a network disruption between the client and the etcd member. etcd may also abort operations when there is a leader election. etcd does not send `abort` responses to  clients’ outstanding requests in this event.
 
-#### revision
+#### Revision
 
 An etcd operation that modifies the key value store is assigned with a single increasing revision. A transaction operation might modifies the key value store multiple times, but only one revision is assigned. The revision attribute of a key value pair that modified by the operation has the same value as the revision of the operation. The revision can be used as a logical clock for key value store. A key value pair that has a larger revision is modified after a key value pair with a smaller revision. Two key value pairs that have the same revision are modified by an operation "concurrently".
 
-### Guarantees Provided
+### Guarantees provided
 
 #### Atomicity
 
@@ -60,4 +60,4 @@ etcd ensures linearizability for all other operations by default. Linearizabilit
 [seq_consistency]: https://en.wikipedia.org/wiki/Consistency_model#Sequential_consistency
 [strict_consistency]: https://en.wikipedia.org/wiki/Consistency_model#Strict_consistency
 [serializable_isolation]: https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable
-[Linearizability]: #Linearizability
+[Linearizability]: #Linearizability

Documentation/learning/data_model.md

@@ -1,10 +1,10 @@
-# Data Model
+# Data model
 
 etcd is designed to reliably store infrequently updated data and provide reliable watch queries. etcd exposes previous versions of key-value pairs to support inexpensive snapshots and watch history events (“time travel queries”). A persistent, multi-version, concurrency-control data model is a good fit for these use cases.
 
 etcd stores data in a multiversion [persistent][persistent-ds] key-value store. The persistent key-value store preserves the previous version of a key-value pair when its value is superseded with new data. The key-value store is effectively immutable; its operations do not update the structure in-place, but instead always generates a new updated structure. All past versions of keys are still accessible and watchable after modification. To prevent the data store from growing indefinitely over time from maintaining old versions, the store may be compacted to shed the oldest versions of superseded data.
 
-### Logical View
+### Logical view
 
 The store’s logical view is a flat binary key space. The key space has a lexically sorted index on byte string keys so range queries are inexpensive.
 
@@ -12,7 +12,7 @@ The key space maintains multiple revisions. Each atomic mutative operation (e.g.
 
 A key’s lifetime spans a generation. Each key may have one or multiple generations. Creating a key increments the generation of that key, starting at 1 if the key never existed. Deleting a key generates a key tombstone, concluding the key’s current generation. Each modification of a key creates a new version of the key. Once a compaction happens, any generation ended before the given revision will be removed and values set before the compaction revision except the latest one will be removed.
 
-### Physical View
+### Physical view
 
 etcd stores the physical data as key-value pairs in a persistent [b+tree][b+tree]. Each revision of the store’s state only contains the delta from its previous revision to be efficient. A single revision may correspond to multiple keys in the tree. 
 
@@ -22,4 +22,4 @@ etcd also keeps a secondary in-memory [btree][btree] index to speed up range que
 
 [persistent-ds]: https://en.wikipedia.org/wiki/Persistent_data_structure
 [btree]: https://en.wikipedia.org/wiki/B-tree
-[b+tree]: https://en.wikipedia.org/wiki/B%2B_tree
+[b+tree]: https://en.wikipedia.org/wiki/B%2B_tree