additional renaming (#78)

README.md

@@ -1,9 +1,9 @@
-# Stargate Docs API
+# Stargate JSON API
 
 This project implements the stand-alone JSON API microservice for Stargate.
 JSON API is an HTTP service that gives access to data stored in a Cassandra cluster using a JSON Document based interface.
 
-Specifications and design documents for this service are defined in the [stargate/doc-api](https://github.com/stargate/doc-api) repository.
+Specifications and design documents for this service are defined in the [docs](docs) directory.
 
 The project depends on the [sgv2-quarkus-common](https://github.com/stargate/stargate/blob/main/apis/sgv2-quarkus-common) module, which provides common functionality used by all Stargate V2 APIs.
 

docs/document-api-network-spec.textile → docs/jsonapi-network-spec.textile

@@ -1,4 +1,4 @@
-h1. Document HTTP API Specification
+h1. JSON HTTP API Specification
 
 <span id="tableOfContents">
 
@@ -8,20 +8,20 @@ h1. Document HTTP API Specification
 
 h2(#preamble). Preamble
 
-This document specifies the HTTP API for the Document API, how clients can communicate with the service. See the "Document API Query Specification" for details of data modelling and queries. 
+This document specifies the HTTP API for the JSON API, how clients can communicate with the service. See the "JSON API Query Specification" for details of data modelling and queries.
 
-The target users for the Document API are Javascript developers who interact with the service through a driver or Object Document Mapper (ODM) library such as "Mongoose":https://github.com/Automattic/mongoose. We expect both ODMs and developers not using an ODM to use a client library that manages connections and encoding, and provides a basic idiomatic representation of the Document API. We do not expected developers to construct and make raw requests against the Document API. With that in mind the HTTP API is designed to be processed by a client side driver first, and humans second. 
+The target users for the JSON API are Javascript developers who interact with the service through a driver or Object Document Mapper (ODM) library such as "Mongoose":https://github.com/Automattic/mongoose. We expect both ODMs and developers not using an ODM to use a client library that manages connections and encoding, and provides a basic idiomatic representation of the JSON API. We do not expected developers to construct and make raw requests against the JSON API. With that in mind the HTTP API is designed to be processed by a client side driver first, and humans second.
 
 The HTTP API has the following design principles: 
 
 # *Message Based:* With the exclusion of the endpoint address and client security context, the entire request from a client and response from the server *should* be encapsulated in a single message in the body of the request. As an illustration, it should be possible to easy capture, store, and later send a request message to a different endpoint and compare the response message to the original response. 
-# *Always Respond:* The Document API *should* always send a response message, even in the case of an error, this is a corollary to "Message Based". This means that errors in processing a request, such as authentication errors or a timeout, result in a HTTP @200@ _OK_ response with the error in the body of the message. Exceptions to this will be errors created by intermediate servers between the client and Document API, such as Gateway errors.
+# *Always Respond:* The JSON API *should* always send a response message, even in the case of an error, this is a corollary to "Message Based". This means that errors in processing a request, such as authentication errors or a timeout, result in a HTTP @200@ _OK_ response with the error in the body of the message. Exceptions to this will be errors created by intermediate servers between the client and JSON API, such as Gateway errors.
 # *Always JSON:* All messages passed between the client and server *must* be valid "JSON":https://www.json.org/ documents.
 
 In general HTTP is treated as a synchronous message passing protocol, rather than taking full advantage of it's features such as in a "REST":https://en.wikipedia.org/wiki/Representational_state_transfer API. The motivations for this decision are: 
 
 # *Traffic Management:* By ensuring the message and the address to deliver it to are clearly separated we can more easily manage client traffic, both in real-time and off-line scenarios. Examples include gateways that multiplex traffic during online migration, shadow deployments for new server versions, capture-and-replay of production traffic for testing, or integration with Change Data Capture (CDC) systems.    
-# *API Portability:* By decoupling networking, encoding, and message delivery / RPC activation ("transport" defined in this HTTP API spec) from service functionality ("features" defined in the "Document API Query Specification") alternative transports may more easily be added. A natural path for the Document API may be to also provide a "gRPC":https://grpc.io/ as the "Stargate":https://stargate.io/ project already provides a gRPC transport for Cassandra's CQL. By not leveraging HTTP verbs or URL path and query patterns we provide a simpler public interface (i.e. a synchronous deliver message with reply) that can easily be replicated. 
+# *API Portability:* By decoupling networking, encoding, and message delivery / RPC activation ("transport" defined in this HTTP API spec) from service functionality ("features" defined in the "JSON API Query Specification") alternative transports may more easily be added. A natural path for the JSON API may be to also provide a "gRPC":https://grpc.io/ as the "Stargate":https://stargate.io/ project already provides a gRPC transport for Cassandra's CQL. By not leveraging HTTP verbs or URL path and query patterns we provide a simpler public interface (i.e. a synchronous deliver message with reply) that can easily be replicated.
 
 
 This approach is informed by both "gRPC":https://grpc.io/ and "GraphQL":https://graphql.org/.
@@ -36,7 +36,7 @@ Clients send a request message to the server over HTTP, and the server sends a r
 
 h2(#conventions). Conventions 
 
-To aid in specifying the Document API, we will use the following conventions in this document:
+To aid in specifying the JSON API, we will use the following conventions in this document:
 
 * Language rules will be given in a "BNF":http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form -like notation:
 
@@ -129,7 +129,7 @@ p. _Syntax:_
 bc(syntax).. 
 <request-message> ::=  <command>
 
-p. Commands are defined in the "Document API Query Specification" document. For the purpose of this document we are only concerned that they are well formed JSON documents.
+p. Commands are defined in the "JSON API Query Specification" document. For the purpose of this document we are only concerned that they are well formed JSON documents.
 
 p. _Sample:_
 

docs/document-api-spec.textile → docs/jsonapi-spec.textile

@@ -1,4 +1,4 @@
-h1. Document API Query Specification
+h1. JSON API Query Specification
 
 <span id="tableOfContents">
 
@@ -8,15 +8,15 @@ h1. Document API Query Specification
 
 h2(#preamble). Preamble
 
-The target users for the Document API are Javascript developers who interact with the service through a driver or Object Document Mapper (ODM) library such as "Mongoose":https://github.com/Automattic/mongoose. The nature of a Document API lends itself to complex, structured queries that may express compound or multiple operations in a single request. Such as selecting one or more documents and projecting a selection of fields from each, or selecting one or more documents and updating them server side. We consider that most requests are generated via the ODM (for example via "mquery":https://github.com/aheckmann/mquery) which makes it easy for the developer to create complex queries at code time, or at run time in response to the actions taken by a user (such as which fields were updated, or which fields the user wants to see). The implementation of the Document API should therefor be optimized for expressing complex and compound machine generated queries, rather than developers making direct queries via the wire protocol API.      
+The target users for the JSON API are Javascript developers who interact with the service through a driver or Object Document Mapper (ODM) library such as "Mongoose":https://github.com/Automattic/mongoose. The nature of a JSON API lends itself to complex, structured queries that may express compound or multiple operations in a single request. Such as selecting one or more documents and projecting a selection of fields from each, or selecting one or more documents and updating them server side. We consider that most requests are generated via the ODM (for example via "mquery":https://github.com/aheckmann/mquery) which makes it easy for the developer to create complex queries at code time, or at run time in response to the actions taken by a user (such as which fields were updated, or which fields the user wants to see). The implementation of the JSON API should therefor be optimized for expressing complex and compound machine generated queries, rather than developers making direct queries via the wire protocol API.
 
-The API should be implemented using HTTP 1 or 2 using JSON as the accepted and returned content type, however adherence to a design pattern such REST is not recommended. This is because of the above expected use through an ODM, and due to the complexity that can be expressed in the Document API. The specification includes compound operations, such as find and update, to be implemented in the server which do not have a clear mapping to the REST verbs. 
+The API should be implemented using HTTP 1 or 2 using JSON as the accepted and returned content type, however adherence to a design pattern such REST is not recommended. This is because of the above expected use through an ODM, and due to the complexity that can be expressed in the JSON API. The specification includes compound operations, such as find and update, to be implemented in the server which do not have a clear mapping to the REST verbs.
 
-Additionally consideration should be given to implementing that API such that the body of a request can be machine generated and includes all possible information needed to process the request. With the exception of any out of band information such as authentication and possibly the collection name. This approach makes it easier to integrate the Document API service with other data services though the use of templates or code to generate a request.
+Additionally consideration should be given to implementing that API such that the body of a request can be machine generated and includes all possible information needed to process the request. With the exception of any out of band information such as authentication and possibly the collection name. This approach makes it easier to integrate the JSON API service with other data services though the use of templates or code to generate a request.
 
 h2(#concepts). High Level Concepts
 
-The Document API consists of the following high level concepts that are composed to create a request: 
+The JSON API consists of the following high level concepts that are composed to create a request:
 
 * *Namespace:* A logical container representing a distinct storage location and query boundary which can contain multiple collections. May map to a keyspace or database.
 * *Collection:* A logical container of documents that have some meaning to the developer using the API. Often an ODM may map a single developer defined class or type to a collection.
@@ -35,7 +35,7 @@ These concepts are grouped together to form a *Request* sent by client software
 
 h2(#conventions). Conventions 
 
-To aid in specifying the Document API, we will use the following conventions in this document:
+To aid in specifying the JSON API, we will use the following conventions in this document:
 
 * Language rules will be given in a "BNF":http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form -like notation: