└── README.md


/README.md:
--------------------------------------------------------------------------------
 1 | See also: [API Design Cheat Sheet](https://github.com/RestCheatSheet/api-cheat-sheet#api-design-cheat-sheet)
 2 | 
 3 | # Platform-Building Cheat Sheet
 4 | 
 5 | First off, we need to understand what is meant by the term **'platform'** for the organization.
 6 | In todays world, the term 'platform' is such an overused buzzword that it is largely meaningless.
 7 | Platforms exist at many levels in the technology stack: hardware, datacenter, database,
 8 | messaging, etc. and can also be used to describe ecosystems of user experiences.
 9 | 
10 | The view presented here is decidedly business focused: the 'platform' is really the method
11 | of exposing and growing the digital business model and its offerings. So, the following ground rules
12 | define the platform as the digital server-side, back-end data and functionality, leaving the user
13 | experiences to be crafted (whether mobile, web or other) on top of that business functionality.
14 | 
15 | This API-centric definition of 'platform' enables:
16 | 
17 | * Rapid user experience revision
18 | * Consistent user experience across devices
19 | * Better channel adaptation
20 | * Faster and cheaper third-party integrations
21 | * Increased innovation capabilities.
22 | 
23 | ## Platform Ground Rules
24 | 
25 | 1. **Mobile** applications are a first-class citizen and consumer of the platform.
26 | 	* Making mobile a priority increases ease of use and adoption for everyone.
27 | 1. The platform exposes its data and functionality via a complete set of **RESTful APIs**.
28 | 	* An API-based strategy maximizes reuse and flexibility.
29 | 1. All service interfaces and events are designed from the ground up to be **public facing**.
30 | 	* Causes design for ease of use, flexibility and reuse.
31 | 1. Each team of developers access all APIs using their team's own **registered developer key**.
32 | 	* Improves security, auditability.
33 | 1. There is a **single token source** and format for all APIs.
34 | 	* Assists in ease of use and ensures all functionality is available to consumers.
35 | 1. The platform will notify interested observers of all resource state changes via **fully-composed events**.
36 | 	* Enables synchronization asynchronously (for all create, update, delete state changes).
37 | 1. All APIs use a **single identity** to represent the consumer / user.
38 | 	* Enables analytics and reasoning about consumers.
39 | 1. All APIs have a **consistent look and feel**, and are documented at a single, publicly-available location.
40 | 	* Maximizes reuse and ease of use.
41 | 1. No private interfaces. **No backdoors**. No shared databases across teams (Observe 'Bounded Contexts').
42 | 	* Ensures the public interfaces are sound.
43 | 1. APIs are deployed in a **distributed, always-on** architecture (multi-node, multi-zone, and multi-region) with a discipline towards resilience.
44 | 	* Horizontal scale on commodity hardware, global reach. Account for the inevitable failures.
45 | 


--------------------------------------------------------------------------------