Merge branch 'master' of https://github.com/biberli/azure-rest-api-specs

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,8 +1,8 @@
-This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process. 
+This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.
 
 ### PR information
 - [ ] The title of the PR is clear and informative.
-- [ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, [see this page](https://github.com/Azure/azure-powershell/blob/dev/documentation/cleaning-up-commits.md).
+- [ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, [see this page](https://github.com/Azure/azure-powershell/blob/master/documentation/development-docs/cleaning-up-commits.md).
 - [ ] Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
 - [ ] If applicable, the PR references the bug/issue that it fixes.
 - [ ] Swagger files are correctly named (e.g. the `api-version` in the path should match the `api-version` in the spec).
@@ -11,5 +11,5 @@ This checklist is used to make sure that common issues in a pull request are add
 - [ ] I have read the [contribution guidelines](https://github.com/Azure/azure-rest-api-specs/blob/master/.github/CONTRIBUTING.md).
 - [ ] My spec meets the review criteria:
   - [ ] The spec conforms to the [Swagger 2.0 specification](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md).
-  - [ ] The spec follows the guidelines described in the [Swagger checklist](../documentation/swagger-checklist.md) document.
-  - [ ] [Validation tools](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-checklist.md#validation-tools-for-swagger-checklist) were run on swagger spec(s) and have all been fixed in this PR. 
+  - [ ] The spec follows the guidelines described in the [Swagger checklist](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-checklist.md) document.
+  - [ ] [Validation tools](https://github.com/Azure/azure-rest-api-specs/blob/master/documentation/swagger-checklist.md#validation-tools-for-swagger-checklist) were run on swagger spec(s) and have all been fixed in this PR.

.travis.yml

@@ -7,8 +7,10 @@ env:
   matrix:
     - MODE=syntax
     - MODE=python
-  # - MODE=node
+    - MODE=node
     - MODE=ruby
+    - MODE=java
+    - MODE=go
     - MODE=semantic PR_ONLY=true
     - MODE=semantic PR_ONLY=false
     - MODE=model PR_ONLY=false
@@ -27,6 +29,9 @@ matrix:
     - env: MODE=BreakingChange PR_ONLY=true
     - env: MODE=azurebot PR_ONLY=true
     - env: MODE=liveValidation PR_ONLY=true
+    - env: MODE=java
+    - env: MODE=go
+    - env: MODE=node
 before_install:
   - docker pull lmazuel/swagger-to-sdk
   - python -c "import os; print('\n'.join(v for v in os.environ.keys() if v.startswith('TRAVIS')))" > /tmp/env_file
@@ -43,15 +48,23 @@ script:
   - DOCKER_CMD="docker run --rm --env-file /tmp/env_file -e GH_TOKEN -v $PWD:/git-restapi/ lmazuel/swagger-to-sdk"
   - >-
     if [[ $MODE == 'python' ]]; then
-      $DOCKER_CMD AutorestCI/azure-sdk-for-python --pr-repo-id Azure/azure-sdk-for-python -o master -v
+      $DOCKER_CMD Azure/azure-sdk-for-python -v
     fi
   - >-
     if [[ $MODE == 'node' ]]; then
-      $DOCKER_CMD AutorestCI/azure-sdk-for-node --pr-repo-id Azure/azure-sdk-for-node -o master -v
+      $DOCKER_CMD Azure/azure-sdk-for-node -v
     fi
   - >-
     if [[ $MODE == 'ruby' ]]; then
-      $DOCKER_CMD AutorestCI/azure-sdk-for-ruby --pr-repo-id Azure/azure-sdk-for-ruby -o master -v
+      $DOCKER_CMD Azure/azure-sdk-for-ruby -v
+    fi
+  - >-
+    if [[ $MODE == 'go' ]]; then
+      $DOCKER_CMD Azure/azure-sdk-for-go -o latest -v
+    fi
+  - >-
+    if [[ $MODE == 'java' ]]; then
+      $DOCKER_CMD Azure/azure-libraries-for-java -v
     fi
   - >-
     if [[ $MODE == 'syntax' ]]; then

README.md

@@ -33,18 +33,20 @@ The structure of the directory should strictly follow these rules:
 
 1. **Profile**: The profile holder contains the profiles' definition MD files. these files will contain information and references to the snapshots of the RPs' Resource types or Dataplane API versions that represent a specific profile.
 
-2. **Specification**: This folder the is root folder for all Specs (Management and Dataplane) related docs. 
+1. **Specification**: This folder the is root folder for all Specs (Management and Dataplane) related docs.
 
-3. **<RP-Name>** Folders - each RP will have a seperate folder
+1. **{RP-Name} Folders** - each RP will have a separate folder
 
-4. **'resource-manager' and 'data-plane' Folders**: the RPs can put specs in one of two categories: `resource-manager` (for ARM resources) and `data-plane` (for everything else) . The autorest configuration file (`readme.md`) for the RP should be inside this folder 
+1. **'resource-manager' and 'data-plane' Folders**: the RPs can put specs in one of two categories: `resource-manager` (for ARM resources) and `data-plane` (for everything else) . The autorest configuration file (`readme.md`) for the RP should be inside this folder
 
-4. **API versions**: this folder will be the direct child of the category folder. there will be one such folder per resource type or dataplane service version. This folder will contain the OpenAPI validation Specs (Swaggers previously) and the examples folder. 
+1. **'preview' and 'stable' Folders**: Varying levels of stability exist in our repository. Each API Version folder should be categorized as either still accepting breaking changes, or no longer accepting breaking changes. This is not a direct analog for whether or not an API Version has the "-preview" suffix or not. SDKs that are generated from 'preview' folder items should indicate to their customers in the most idiomatic way that breaking changes may still be coming.
 
-6. **Examples**: the example folder will contain the x-ms-examples files. it will reside under the APIs or Resources' version folders as different APIs or Resource types version can have different examples. 
+1. **API versions**: this folder will be the direct child of the category folder. there will be one such folder per resource type or dataplane service version. This folder will contain the OpenAPI validation Specs (Swaggers previously) and the examples folder.
 
-7. **Notes**: 
-    - folder names should be singular (ie, 'profile' not 'profiles' ) -- this removes ambiguity for some non-english speakers. 
+1. **Examples**: the example folder will contain the x-ms-examples files. it will reside under the APIs or Resources' version folders as different APIs or Resource types version can have different examples.
+
+1. **Notes**:
+    - folder names should be singular (ie, 'profile' not 'profiles' ) -- this removes ambiguity for some non-english speakers.
     - generic folder names should be lower-case
     - proper-name/product name/namespace folders can be PascalCased (ie, "KeyVault")
     - files are whatever case you think is good for your soul.
@@ -57,31 +59,37 @@ The structure should appear like so:
 |    +---automation
 |    |   \---resource-manager
 |    |       \---Microsoft.Automation
-|    |           \---2015-10-31
-|    |               \---examples
+|    |           \---stable
+|    |               \---2015-10-31
+|    |                   \---examples
 |    +---batch
 |    |   +---data-plane
 |    |   |   \---Microsoft.Batch
-|    |   |       +---2015-12-01.2.2
-|    |   |       +---2016-02-01.3.0
-|    |   |       +---2016-07-01.3.1
-|    |   |       +---2017-01-01.4.0
-|    |   |       |   \---examples
-|    |   |       \---2017-05-01.5.0
+|    |   |       +---stable
+|    |   |       |   +---2015-12-01.2.2
+|    |   |       |   +---2016-02-01.3.0
+|    |   |       |   +---2016-07-01.3.1
+|    |   |       |   +---2017-01-01.4.0
+|    |   |       |       \---examples
+|    |   |       \---preview
+|    |   |           \---2017-05-01.5.0
 |    |   \---resource-manager
 |    |       \---Microsoft.Batch
-|    |           +---2015-12-01
-|    |           +---2017-01-01
-|    |           |   \---examples
+|    |           +---stable
+|    |           |   +---2015-12-01
+|    |           |   +---2017-01-01
+|    |           |       \---examples
 |    |           \---2017-05-01
 |    |               \---examples
 |    +---billing
 |        \---resource-manager
 |            \---Microsoft.Billing
-|                +---2017-02-27-preview
-|                |   \---examples
-|                \---2017-04-24-preview
-|                    \---examples
+|                \---stable
+|                |   +---2017-02-27-preview
+|                |       \---examples
+|                +---preview
+|                    \---2017-04-24-preview
+|                        \---examples
 \--- readme.md
 ```
 

documentation/creating-swagger.md

@@ -414,6 +414,35 @@ Please note, that the use of "x-ms-paths" should be minimized to the above scena
 The request body and response definitions become simple model types in the generated code. The models include 
 basic validation methods, but are generally stateless serialization definitions.
 
+### Understanding the importance of "type" keyword while definining model types.
+"Type-specific" keywords such as properties, items, minLength, etc. do not enforce a type on the schema. It works the other way around – when an instance is validated against a schema, these keywords only apply when the instance is of the corresponding type, otherwise they are ignored. Here's the relevant part of the [JSON Schema Validation](https://tools.ietf.org/html/draft-fge-json-schema-validation-00#section-4.1) spec:
+
+> 4.1. Keywords and instance primitive types
+Some validation keywords only apply to one or more primitive types. When the primitive type of the instance cannot be validated by a given keyword, validation for this keyword and instance SHOULD succeed.
+
+For example, consider this schema:
+
+```yaml
+definitions:
+  Something:
+    properties:
+      id:
+        type: integer
+    required: [id]
+    minLength: 8
+```
+It's a valid schema, even though it combines object-specific keywords properties and required and string-specific keyword minLength. This schema means:
+- If the instance is an object, it must have an integer property named id. For example, `{"id": 4}` and `{"id": -1, "foo": "bar"}` are valid, but `{}` and `{"id": "ACB123"}` are not.
+- If the instance is a string, it must contain at least 8 characters. `"Hello, world!"` is valid, but `""` and `abc` are not.
+- Any instances of other types are valid - `true`, `false`, `-1.234`, `[]`, `[1, 2, 3]`, `[1, "foo", true]`, etc.
+(Except `null` - OpenAPI 2.0 does not have the `null` type and does not support `null` except in extension properties. OpenAPI 3.0 supports the `null` value for schemas with nullable: true.)
+
+If there are tools that infer the `type` from other keywords (for example, handle schemas with no `type` but with `properties` as always objects), then these tools are not exactly following the OpenAPI Specification and JSON Schema.
+
+> Bottom line: If a schema must always be an object, add `"type": "object"` explicitly. Otherwise you might get unexpected results.
+
+**Credits** - Stack Overflow [link](https://stackoverflow.com/questions/47374980/schema-object-without-a-type-attribute-in-swagger-2-0).
+
 ### Model Inheritance<a name="ModelInheritance"></a>
 Swagger schema allows for specifying that one type is `allOf` other types, meaning that the entire specification of 
 the referenced schema applies is included in the new schema. By convention, if a schema has an 'allOf' that references