Changes related to Apiary and Mashery. Also related to LRTs cases and mentions to SwaggerHub.

Author: jesusjavierdediegoadidas

.gitignore

@@ -105,3 +105,5 @@ dist
 
 # SSHFS
 ._*
+
+.DS_Store

README.md

@@ -4,7 +4,7 @@ description: Guidelines for the API design and development at adidas
 
 # adidas API Guidelines
 
-![adidas logo](https://adidas-group.gitbooks.io/api-guidelines/content/assets/adidas-logo.svg)
+![adidas logo](adidaslogo.jpg)
 
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
 
@@ -23,7 +23,7 @@ The API Guidelines are split into two main parts:
 * [General Guidelines](general-guidelines/general-guidelines.md)
 * API type-specific Guidelines
   * [REST APIs Guidelines](rest-api-guidelines/rest.md)
-  * [Kafka Guidelines](kafka-guidelines/kafka.md)
+  * [Asynchronous APIs Guidelines](asynchronous-api-guidelines/asyncapi.md)
 
 The general guidelines section discusses the core principles relevant to any kind of API. The API type-specific section further defines the guidelines specific to a given architectural style or API technique \(such as REST, Kafka or GraphQL APIs\).
 
@@ -83,5 +83,5 @@ For further information open the [adidas terms and conditions](https://github.co
 
 ### License
 
-[MIT](https://github.com/adidas-group/api-guidelines/tree/657bc6fd49f1499f10c30ab18420f4bdb7cd841b/LICENSE/README.md)
+[MIT](https://github.com/adidas/api-guidelines/blob/master/LICENSE)
 

SUMMARY.md

@@ -21,6 +21,7 @@
   * [OpenAPI Specification](rest-api-guidelines/core-principles/openapi-specification.md)
   * [API Design Platform](rest-api-guidelines/core-principles/design-platform.md)
   * [Design Maturity](rest-api-guidelines/core-principles/design-maturity.md)
+  * [HATEOAS](rest-api-guidelines/core-principles/HATEOAS.md)
   * [Testing](rest-api-guidelines/core-principles/testing.md)
 * [Protocol](rest-api-guidelines/protocol/README.md)
   * [HTTP](rest-api-guidelines/protocol/http.md)
@@ -39,7 +40,10 @@
   * [Common Data Types](rest-api-guidelines/application/common-data-types.md)
 * [Execution](rest-api-guidelines/execution/README.md)
   * [Pagination](rest-api-guidelines/execution/pagination.md)
-  * [Asynchronous Tasks](rest-api-guidelines/execution/asynchronous-tasks.md)
+  * [Long Running Tasks](rest-api-guidelines/execution/long-running-tasks/README.md)
+    * [Polling](rest-api-guidelines/execution/long-running-tasks/polling.md)
+    * [Callback](rest-api-guidelines/execution/long-running-tasks/callback.md)
+    * [Files Upload](rest-api-guidelines/execution/long-running-tasks/files-upload.md)
   * [Batch Operations](rest-api-guidelines/execution/batch-operations.md)
   * [Search Requests](rest-api-guidelines/execution/search-requests.md)
   * [Query Requests with Large Inputs](rest-api-guidelines/execution/query-requests-with-large-inputs.md)
@@ -61,7 +65,10 @@
   * [Loose Coupling](rest-api-guidelines/clients/loose-coupling.md)
 * [Further References](rest-api-guidelines/miscellaneous.md)
 
-## Kafka Guidelines
+## Asynchronous API Guidelines
 
-* [Introduction](kafka-guidelines/kafka.md)
+* [Introduction](asynchronous-api-guidelines/asyncapi.md)
+* [Core Principles](asynchronous-api-guidelines/core-principles/README.md)
+* [Platforms](asynchronous-api-guidelines/platforms/README.md)
+* [Types](asynchronous-api-guidelines/types/README.md)
 

adidaslogo.jpg

@@ -0,0 +1,6 @@
+# Introduction
+
+## adidas Asynchronous APIs Guidelines
+
+
+

asynchronous-api-guidelines/asyncapi.md

@@ -9,3 +9,7 @@ Any JSON-based message **MUST** conform to the following rules:
 5. Empty arrays and objects **SHOULD NOT**  be `null` \(use `[]` or `{}` instead\)
 6. Array field names **SHOULD** be plural \(e.g. `"orders": []`\)
 
+## Validation
+All API designers **MUST** validate the definition of the payloads in requests/responses with the [JSON Schema](https://json-schema.org/) for the defined structure prior to the publication of the API Contract in SwaggerHub.
+
+The publication of the JSON schema corresponding to the expected payloads in the bodies of requests and responses **SHOULD** be kept up to date according to the evolution of the API. 

general-guidelines/json.md

@@ -1,6 +1,6 @@
 # API Design Platform
 
-1. [SwaggerHub](https://swagger.io/tools/swaggerhub/) is the primary platform supporting [API first approach](../../general-guidelines/api-first.md). SwaggerHub **SHOULD** be used during API Design.
+1. [SwaggerHub](https://design.api.3stripes.io/) is the primary platform supporting [API first approach](../../general-guidelines/api-first.md). SwaggerHub **MUST** be used during API Design.
 2. Every API description **MUST** be stored in [SwaggerHub](https://design.api.3stripes.io/) under the adidas team.
 3. SwaggerHub **MUST** be the **single source of truth** to learn about existing APIs within the organization.
 

kafka-guidelines/kafka.md

@@ -1,6 +1,6 @@
 # OpenAPI Specification
 
-Every API **MUST** be described using an API description format. The API description format used MUST be the [OpenAPI Specification \(formerly known as Swagger Specification\) version 2.0](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md).
+Every API **MUST** be described using an API description format. The API description format used MUST be the [OpenAPI Specification \(formerly known as Swagger Specification\) version 2.0](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md) OR the[OpenAPI Specification \(formerly known as Swagger Specification\) version 3.0.x](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md).
 
 Every API description **MUST** be published in adidas [API design platform](design-platform.md) and it **SHOULD** be stored in version control system \(Bitbucket, GitHub\) in the same repository as the API implementation.
 

rest-api-guidelines/core-principles/design-platform.md

@@ -2,7 +2,7 @@
 
 ## Processing Similar Resources
 
-An operation that needs to process several related resources in bulk **SHOULD** use a collection resource with the appropriate HTTP Request Method. When processing existing resource the request message body **MUST** contain the URLs of the respective resources being processed.
+An operation that needs to process several related resources in bulk **SHOULD** uses a collection resource with the appropriate HTTP Request Method. When processing existing resource the request message body **MUST** contain the URLs of the respective resources being processed.
 
 ### Example