docs: fix naming - use API Client isntead of SDK

Fixes #1138

Signed-off-by: Youngone Lee <[email protected]>

Author: Leeyoungone

CONTRIBUTING.md

@@ -17,7 +17,7 @@
     - [Debugging a test case](#debugging-a-test-case)
   - [All-In-One Docker Images for Ledger Connector Plugins](#all-in-one-docker-images-for-ledger-connector-plugins)
     - [Test Automation of Ledger Plugins](#test-automation-of-ledger-plugins)
-  - [Building the SDK](#building-the-sdk)
+  - [Building the API Client(S)](#building-the-api-clients)
   - [Adding new dependencies:](#adding-new-dependencies)
   - [Reload VSCode Window After Adding Dependencies](#reload-vscode-window-after-adding-dependencies)
   - [On Reproducible Builds](#on-reproducible-builds)
@@ -496,19 +496,21 @@ npx tap --ts --jobs=1 --timeout=600 \"./\"
 > Be aware that glob patterns need quoting in some operating system's shell environments and not necessarily on others.
 > In the npm scripts Cactus uses we quote all of them to ensure a wider shell compatibility.
 
-### Building the SDK
+### Building the API Client(S)
 
-You do not need to do anything special to have the SDK sources generated and
+You do not need to do anything special to have the API Client sources generated and
 compiled. It is all part of the `npm run build:dev:backend` task which you can run yourself
 or as part of the CI script (`./tools/ci.sh`).
 
-The SDK is itself just another package named `sdk` and can be dependend on by
-other packages where applicable.
+The API client code is automatically generated from the respective `openapi.json` file of each package that exposes ay web serices (REST/SocketIO/gRPC/etc.) and can be dependend on by
+other packages where applicable. There's a dedicated `@hyperledger/cactus-api-client` package that is meant to contain common functionality among the rest of API clients. The concept here is similar to abstract classes and their sub-class implementations. 
 
-The SDK is designed to be a universal package meaning that it runs just fine in
+Each `openapi.json` produces its own API client via the code generator that also contains relevant model definitions, such as interfaces describing the request/response bodies of all possible operations and validation constraints as well. 
+
+The API clients are designed to be a universal components, meaning that it runs just fine in
 browser and also NodeJS environments. This is very important as we do not wish
-to maintain two (or more) separate SDK codebases and we also want as much of it
-being generated automatically as possible (currently this is close to 100%).
+to maintain two (or more) separate API client codebases for the various platforms and we also want as much of it being generated automatically as possible (currently this is close to 100%).
+
 
 ### Adding new dependencies:
 

whitepaper/whitepaper.md

@@ -101,7 +101,7 @@ Photo by Pontus Wellgraf on Unsplash
         - [5.4.1.1.2 Configuration Schema - API Server](#54112-configuration-schema---api-server)
         - [5.4.1.1.3 Plugin Loading/Validation](#54113-plugin-loadingvalidation)
       - [5.4.1.2 core-api](#5412-core-api)
-      - [5.4.1.3 sdk](#5413-sdk)
+      - [5.4.1.3 API Client](#5413-api-client)
       - [5.4.1.4 keychain](#5414-keychain)
       - [5.4.1.5 tracing](#5415-tracing)
       - [5.4.1.6 audit](#5416-audit)
@@ -1112,7 +1112,6 @@ All packages have a prefix of `cactus-*` to avoid potential naming conflicts wit
 
 Naming conventions for packages:
 * cmd-* for packages that ship their own executable
-* sdk-* for packages designed to be used directly by application developers except for the Javacript SDK which is named just `sdk` for simplicity.
 * All other packages should be named preferably as a single English word suggesting the most important feature/responsibility of the package itself.
 
 #### 5.4.1.1 cmd-api-server
@@ -1235,9 +1234,9 @@ Plugin loading happens through NodeJS's built-in module loader and the validatio
 Contains interface definitions for the plugin architecture and other system level components that are to be shared among many other packages.
 `core-api` is intended to be a leaf package meaning that it shouldn't depend on other packages in order to make it safe for any and all packages to depend on `core-api` without having to deal with circular dependency issues.
 
-#### 5.4.1.3 sdk
+#### 5.4.1.3 API Client
 
-Javascript SDK (bindings) for the RESTful HTTP API provided by `cmd-api-server`.
+Javascript API Client (bindings) for the RESTful HTTP API provided by `cmd-api-server`.
 Compatible with both NodeJS and Web Browser (HTML 5 DOM + ES6) environments.
 
 #### 5.4.1.4 keychain
@@ -1512,10 +1511,10 @@ seen below:
         }
 ```
 
-The configuration above will cause the `Consortium JWS` REST API endpoint (callable via the SDK) to respond with a
+The configuration above will cause the `Consortium JWS` REST API endpoint (callable via the API Client) to respond with a
 consortium JWS that looks similar to what is pasted below.
 
-Code examples of how to use the SDK to call this endpoint can be seen at
+Code examples of how to use the API Client to call this endpoint can be seen at
 `./packages/cactus-cockpit/src/app/consortium-inspector/consortium-inspector.page.ts`
 
 ```json