diff --git a/_data/info/v4/annotations.yml b/_data/info/v4/annotations.yml index 466ab5f2..af52ee02 100644 --- a/_data/info/v4/annotations.yml +++ b/_data/info/v4/annotations.yml @@ -56,7 +56,7 @@ parameters: [] - name: CreatePermission - description: Define security rules for creating an object through Elide. See the security section for more information. + description: Define security rules for creating an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -67,10 +67,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: ReadPermission - description: Define security rules for reading an object through Elide. See the security section for more information. + description: Define security rules for reading an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -81,10 +81,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: UpdatePermission - description: Define security rules for updating an object through Elide. See the security section for more information. + description: Define security rules for updating an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -95,10 +95,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: DeletePermission - description: Define security rules for deleting an object through Elide. See the security section for more information. + description: Define security rules for deleting an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -109,10 +109,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: SharePermission - description: Enable sharing permissions on an object through Elide. See the security section for more information. + description: Enable sharing permissions on an object through Elide. See the security section for more information. applicationLevel: - Method - Class @@ -122,7 +122,7 @@ required: False type: Boolean default: True - description: Enable or disable shareability for an object. Shareable permissions are evaluated identically to an entity's read permissions. See the security section for more information. + description: Enable or disable shareability for an object. Shareable permissions are evaluated identically to an entity's read permissions. See the security section for more information. - name: Exclude description: Marks that a given field or entity should not be exposed through Elide. diff --git a/_data/info/v5/core_annotations.yml b/_data/info/v5/core_annotations.yml index 34df14d9..7f57d783 100644 --- a/_data/info/v5/core_annotations.yml +++ b/_data/info/v5/core_annotations.yml @@ -67,7 +67,7 @@ description: The API Version name. - name: CreatePermission - description: Define security rules for creating an object through Elide. See the security section for more information. + description: Define security rules for creating an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -78,10 +78,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: ReadPermission - description: Define security rules for reading an object through Elide. See the security section for more information. + description: Define security rules for reading an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -92,10 +92,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: UpdatePermission - description: Define security rules for updating an object through Elide. See the security section for more information. + description: Define security rules for updating an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -106,10 +106,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: DeletePermission - description: Define security rules for deleting an object through Elide. See the security section for more information. + description: Define security rules for deleting an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -120,7 +120,7 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: NonTransferable description: Marks that a model cannot be assigned to another collection after its creation. diff --git a/_data/info/v6/core_annotations.yml b/_data/info/v6/core_annotations.yml index 3de41472..b5f5268b 100644 --- a/_data/info/v6/core_annotations.yml +++ b/_data/info/v6/core_annotations.yml @@ -67,7 +67,7 @@ description: The API Version name. - name: CreatePermission - description: Define security rules for creating an object through Elide. See the security section for more information. + description: Define security rules for creating an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -78,10 +78,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: ReadPermission - description: Define security rules for reading an object through Elide. See the security section for more information. + description: Define security rules for reading an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -92,10 +92,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: UpdatePermission - description: Define security rules for updating an object through Elide. See the security section for more information. + description: Define security rules for updating an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -106,10 +106,10 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: DeletePermission - description: Define security rules for deleting an object through Elide. See the security section for more information. + description: Define security rules for deleting an object through Elide. See the security section for more information. applicationLevel: - Field - Method @@ -120,7 +120,7 @@ required: True type: String default: None - description: A security expression parsed by Elide security. See the security section for more information. + description: A security expression parsed by Elide security. See the security section for more information. - name: NonTransferable description: Marks that a model cannot be assigned to another collection after its creation. diff --git a/pages/guide/v4/02-data-model.md b/pages/guide/v4/02-data-model.md index 3ea466b2..5eb46022 100644 --- a/pages/guide/v4/02-data-model.md +++ b/pages/guide/v4/02-data-model.md @@ -29,7 +29,7 @@ version: 4 --------------------- -Elide generates its API entirely based on the concept of **data models**. Data models are Java classes that represent both a concept to your application and also the _schema_ of an exposed web service endpoint. Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datatstores.html) or the set of data stores which support your Elide-based service. +Elide generates its API entirely based on the concept of **data models**. Data models are Java classes that represent both a concept to your application and also the _schema_ of an exposed web service endpoint. Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datastores.html) or the set of data stores which support your Elide-based service. All Elide models have an identifier field that identifies a unique instance of the model. Models are also composed of optional attributes and relationships. Attribute are properties of the model. Relationships are simply links to other related Elide models. Annotations are used to declare that a class is an Elide model, that a relationship exists between two models, to denote which field is the identifier field, and to [secure the model]({{site.baseurl}}/pages/guide/v{{ page.version }}/03-security.html). @@ -415,7 +415,7 @@ Entity inheritance has a few caveats: ## Philosophy -Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datatstores.html) or the set of data stores which support your Elide-based service. While other JPA-based workflows often encourage writing data models that exactly match the underlying schema of the data store, we propose a strategy of isolation on per-service basis. Namely, we recommend creating a data model that only supports precisely the bits of data you need from your underlying schema. Often times there will be no distinction when first building your systems. However, as your systems scale and you develop multiple services with overlapping data store requirements, isolation often serves as an effective tool to **reduce interdependency** among services and **maximize the separation of concern**. Overall, while models can correspond to your underlying data store schema as a one-to-one representation, it's not always strictly necessary and sometimes even undesirable. +Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datastores.html) or the set of data stores which support your Elide-based service. While other JPA-based workflows often encourage writing data models that exactly match the underlying schema of the data store, we propose a strategy of isolation on per-service basis. Namely, we recommend creating a data model that only supports precisely the bits of data you need from your underlying schema. Often times there will be no distinction when first building your systems. However, as your systems scale and you develop multiple services with overlapping data store requirements, isolation often serves as an effective tool to **reduce interdependency** among services and **maximize the separation of concern**. Overall, while models can correspond to your underlying data store schema as a one-to-one representation, it's not always strictly necessary and sometimes even undesirable. As an example, let's consider a situation where you have two Elide-based microservices: one for your application backend and another for authentication (suppose account creation is performed out-of-band for this example). Assuming both of these rely on a common data store, they'll both likely want to recognize the same underlying _User_ table. However, it's quite likely that the authentication service will only ever require information about user **credentials** and the application service will likely only ever need user **metadata**. More concretely, you could have a system that looks like the following: diff --git a/pages/guide/v4/09-clientapis.md b/pages/guide/v4/09-clientapis.md index 09ad2a11..70c84cdc 100644 --- a/pages/guide/v4/09-clientapis.md +++ b/pages/guide/v4/09-clientapis.md @@ -123,8 +123,8 @@ This can be toggled by overriding the `Elide` autoconfigure bean: ##### Elide Library Configuration If using Elide as a library, the following date serdes can be registered: -1. [IS8601 Serde](https://github.com/yahoo/elide/blob/master/elide-core/src/main/java/com/yahoo/elide/utils/coerce/converters/ISO8601DateSerde.java) -2. [Epoch Serde](https://github.com/yahoo/elide/blob/master/elide-core/src/main/java/com/yahoo/elide/utils/coerce/converters/EpochToDateConverter.java) +1. [ISO8601 Serde](https://github.com/yahoo/elide/blob/master/elide-core/src/main/java/com/yahoo/elide/core/utils/coerce/converters/ISO8601DateSerde.java) +2. [Epoch Serde](https://github.com/yahoo/elide/blob/master/elide-core/src/main/java/com/yahoo/elide/core/utils/coerce/converters/EpochToDateConverter.java) #### UUID Coercion diff --git a/pages/guide/v4/13-swagger.md b/pages/guide/v4/13-swagger.md index 833e2fe7..605753ba 100644 --- a/pages/guide/v4/13-swagger.md +++ b/pages/guide/v4/13-swagger.md @@ -165,7 +165,7 @@ String jsonOutput = SwaggerBuilder.getDocument(document); #### Configure JAX-RS Endpoint -Or you can use the Swagger document directly to configure the [provided JAX-RS Endpoint](https://github.com/yahoo/elide/blob/master/elide-contrib/elide-swagger/src/main/java/com/yahoo/elide/contrib/swagger/resources/DocEndpoint.java): +Or you can use the Swagger document directly to configure the [provided JAX-RS Endpoint](https://github.com/yahoo/elide/blob/master/elide-swagger/src/main/java/com/yahoo/elide/swagger/resources/DocEndpoint.java): ```java Map swaggerDocs = new HashMap<>(); diff --git a/pages/guide/v4/14-test.md b/pages/guide/v4/14-test.md index 5d020cf5..676327a3 100644 --- a/pages/guide/v4/14-test.md +++ b/pages/guide/v4/14-test.md @@ -5,7 +5,7 @@ title: Test version: 4 --- -The [elide-test-helpers](https://github.com/yahoo/elide/tree/master/elide-contrib/elide-test-helpers) package provides a JSON-API and GraphQL +The [elide-test-helpers](https://github.com/yahoo/elide/tree/master/elide-test) package provides a JSON-API and GraphQL type safe DSL that simplifies adding integration tests to your service. The DSLs are designed to work with [Rest Assured](http://rest-assured.io/). ## Dependencies @@ -15,7 +15,7 @@ The tests described here are based on a [the getting started example repo][elide The example leverages: 1. [Elide Spring Boot Starter][elide-spring] for running the test service and setting up Elide. 2. [JUnit 5](https://junit.org/junit5/) for adding tests. -3. [elide-test-helpers](https://github.com/yahoo/elide/tree/master/elide-contrib/elide-test-helpers) for the JSON-API and GraphQL DSLs. +3. [elide-test-helpers](https://github.com/yahoo/elide/tree/master/elide-test) for the JSON-API and GraphQL DSLs. 4. [Rest Assured](http://rest-assured.io/) for issuing HTTP requests against the test service. 5. [Spring Boot Test Starter](https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-test) for adding test data for each test. 6. [H2 In Memory Database](https://www.h2database.com/html/main.html) for an in memory test database. @@ -127,7 +127,7 @@ Using Rest Assured and the JSON-API DSL, you can issue JSON-API requests and ver } ``` -The complete set of static DSL operators for JSON-API can be found [here](https://github.com/yahoo/elide/blob/master/elide-contrib/elide-test-helpers/src/main/java/com/yahoo/elide/contrib/testhelpers/jsonapi/JsonApiDSL.java). +The complete set of static DSL operators for JSON-API can be found [here](https://github.com/yahoo/elide/blob/master/elide-test/src/main/java/com/yahoo/elide/test/jsonapi/JsonApiDSL.java). ## GraphQL DSL @@ -185,7 +185,7 @@ Using Rest Assured and the GraphQL DSL, you can issue GraphQL requests and verif ``` -The complete set of static DSL operators for GraphQL can be found [here](https://github.com/yahoo/elide/blob/master/elide-contrib/elide-test-helpers/src/main/java/com/yahoo/elide/contrib/testhelpers/graphql/GraphQLDSL.java). +The complete set of static DSL operators for GraphQL can be found [here](https://github.com/yahoo/elide/blob/master/elide-test/src/main/java/com/yahoo/elide/test/graphql/GraphQLDSL.java). [elide-demo]: https://github.com/yahoo/elide-spring-boot-example [elide-spring]: https://github.com/yahoo/elide/tree/master/elide-spring/elide-spring-boot-starter diff --git a/pages/guide/v5/02-data-model.md b/pages/guide/v5/02-data-model.md index ffd4483f..e614bfaa 100644 --- a/pages/guide/v5/02-data-model.md +++ b/pages/guide/v5/02-data-model.md @@ -29,7 +29,7 @@ version: 5 --------------------- -Elide generates its API entirely based on the concept of **data models**. Data models are JVM classes that represent both a concept to your application and also the _schema_ of an exposed web service endpoint. Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datatstores.html) or the set of data stores which support your Elide-based service. +Elide generates its API entirely based on the concept of **data models**. Data models are JVM classes that represent both a concept to your application and also the _schema_ of an exposed web service endpoint. Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datastores.html) or the set of data stores which support your Elide-based service. All Elide models have an identifier field that identifies a unique instance of the model. Models are also composed of optional attributes and relationships. Attribute are properties of the model. Relationships are simply links to other related Elide models. Annotations are used to declare that a class is an Elide model, that a relationship exists between two models, to denote which field is the identifier field, and to [secure the model]({{site.baseurl}}/pages/guide/v{{ page.version }}/03-security.html). @@ -348,7 +348,7 @@ Details of how to construct client queries for a specific version can be found [ ## Philosophy -Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datatstores.html) or the set of data stores which support your Elide-based service. While other JPA-based workflows often encourage writing data models that exactly match the underlying schema of the data store, we propose a strategy of isolation on per-service basis. Namely, we recommend creating a data model that only supports precisely the bits of data you need from your underlying schema. Often times there will be no distinction when first building your systems. However, as your systems scale and you develop multiple services with overlapping data store requirements, isolation often serves as an effective tool to **reduce interdependency** among services and **maximize the separation of concern**. Overall, while models can correspond to your underlying data store schema as a one-to-one representation, it's not always strictly necessary and sometimes even undesirable. +Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datastores.html) or the set of data stores which support your Elide-based service. While other JPA-based workflows often encourage writing data models that exactly match the underlying schema of the data store, we propose a strategy of isolation on per-service basis. Namely, we recommend creating a data model that only supports precisely the bits of data you need from your underlying schema. Often times there will be no distinction when first building your systems. However, as your systems scale and you develop multiple services with overlapping data store requirements, isolation often serves as an effective tool to **reduce interdependency** among services and **maximize the separation of concern**. Overall, while models can correspond to your underlying data store schema as a one-to-one representation, it's not always strictly necessary and sometimes even undesirable. As an example, let's consider a situation where you have two Elide-based microservices: one for your application backend and another for authentication (suppose account creation is performed out-of-band for this example). Assuming both of these rely on a common data store, they'll both likely want to recognize the same underlying _User_ table. However, it's quite likely that the authentication service will only ever require information about user **credentials** and the application service will likely only ever need user **metadata**. More concretely, you could have a system that looks like the following: diff --git a/pages/guide/v5/13-swagger.md b/pages/guide/v5/13-swagger.md index 553323e7..9c5f34cd 100644 --- a/pages/guide/v5/13-swagger.md +++ b/pages/guide/v5/13-swagger.md @@ -201,7 +201,7 @@ String jsonOutput = SwaggerBuilder.getDocument(document); #### Configure JAX-RS Endpoint -Or you can use the Swagger document directly to configure the [provided JAX-RS Endpoint](https://github.com/yahoo/elide/blob/master/elide-swagger/src/main/java/com/yahoo/elide/contrib/swagger/resources/DocEndpoint.java): +Or you can use the Swagger document directly to configure the [provided JAX-RS Endpoint](https://github.com/yahoo/elide/blob/master/elide-swagger/src/main/java/com/yahoo/elide/swagger/resources/DocEndpoint.java): ```java Map swaggerDocs = new HashMap<>(); diff --git a/pages/guide/v5/14-test.md b/pages/guide/v5/14-test.md index b3ddfc86..984a082d 100644 --- a/pages/guide/v5/14-test.md +++ b/pages/guide/v5/14-test.md @@ -127,7 +127,7 @@ Using Rest Assured and the JSON-API DSL, you can issue JSON-API requests and ver } ``` -The complete set of static DSL operators for JSON-API can be found [here](https://github.com/yahoo/elide/blob/master/elide-contrib/elide-test-helpers/src/main/java/com/yahoo/elide/contrib/testhelpers/jsonapi/JsonApiDSL.java). +The complete set of static DSL operators for JSON-API can be found [here](https://github.com/yahoo/elide/blob/master/elide-test/src/main/java/com/yahoo/elide/test/jsonapi/JsonApiDSL.java). ## GraphQL DSL @@ -185,7 +185,7 @@ Using Rest Assured and the GraphQL DSL, you can issue GraphQL requests and verif ``` -The complete set of static DSL operators for GraphQL can be found [here](https://github.com/yahoo/elide/blob/master/elide-contrib/elide-test-helpers/src/main/java/com/yahoo/elide/contrib/testhelpers/graphql/GraphQLDSL.java). +The complete set of static DSL operators for GraphQL can be found [here](https://github.com/yahoo/elide/blob/master/elide-test/src/main/java/com/yahoo/elide/test/graphql/GraphQLDSL.java). [elide-demo]: https://github.com/yahoo/elide-spring-boot-example [elide-spring]: https://github.com/yahoo/elide/tree/master/elide-spring/elide-spring-boot-starter diff --git a/pages/guide/v5/17-migration.md b/pages/guide/v5/17-migration.md index 54edee37..93a42501 100644 --- a/pages/guide/v5/17-migration.md +++ b/pages/guide/v5/17-migration.md @@ -12,8 +12,8 @@ Elide 4 documentation can be found [here]({{site.baseurl}}/pages/guide/v4/01-sta Elide 5 introduces several new features: - A new [semantic modeling layer and analytic query API]({{site.baseurl}}/pages/guide/v{{ page.version }}/04-analytics.html) for OLAP style queries against your database. - - An [asynchronous API](({{site.baseurl}}/pages/guide/v{{ page.version }}/11.5-asyncapi.html)) for API read requests with long durations. - - An [data export API](({{site.baseurl}}/pages/guide/v{{ page.version }}/11.5-asyncapi.html)) for exporting flat models as CSV or JSON. + - An [asynchronous API]({{site.baseurl}}/pages/guide/v{{ page.version }}/11.5-asyncapi.html) for API read requests with long durations. + - An [data export API]({{site.baseurl}}/pages/guide/v{{ page.version }}/11.5-asyncapi.html) for exporting flat models as CSV or JSON. - [A mechanism]({{site.baseurl}}/pages/guide/v{{ page.version}}/02-data-model.html#api-versions) to version elide models and the corresponding API. - The 'hasmember' and 'hasnomember' filter operator supports predicates that traverse to-many relationships (book.authors.name=hasmember='Foo'). - New 'between' and 'notbetween' filter operators. diff --git a/pages/guide/v6/02-data-model.md b/pages/guide/v6/02-data-model.md index ef281103..faa5cf92 100644 --- a/pages/guide/v6/02-data-model.md +++ b/pages/guide/v6/02-data-model.md @@ -30,7 +30,7 @@ version: 6 --------------------- -Elide generates its API entirely based on the concept of **data models**. Data models are JVM classes that represent both a concept to your application and also the _schema_ of an exposed web service endpoint. Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datatstores.html) or the set of data stores which support your Elide-based service. +Elide generates its API entirely based on the concept of **data models**. Data models are JVM classes that represent both a concept to your application and also the _schema_ of an exposed web service endpoint. Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datastores.html) or the set of data stores which support your Elide-based service. All Elide models have an identifier field that identifies a unique instance of the model. Models are also composed of optional attributes and relationships. Attribute are properties of the model. Relationships are simply links to other related Elide models. Annotations are used to declare that a class is an Elide model, that a relationship exists between two models, to denote which field is the identifier field, and to [secure the model]({{site.baseurl}}/pages/guide/v{{ page.version }}/03-security.html). @@ -350,7 +350,7 @@ Details of how to construct client queries for a specific version can be found [ ## Philosophy -Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datatstores.html) or the set of data stores which support your Elide-based service. While other JPA-based workflows often encourage writing data models that exactly match the underlying schema of the data store, we propose a strategy of isolation on per-service basis. Namely, we recommend creating a data model that only supports precisely the bits of data you need from your underlying schema. Often times there will be no distinction when first building your systems. However, as your systems scale and you develop multiple services with overlapping data store requirements, isolation often serves as an effective tool to **reduce interdependency** among services and **maximize the separation of concern**. Overall, while models can correspond to your underlying data store schema as a one-to-one representation, it's not always strictly necessary and sometimes even undesirable. +Data models are intended to be a _view_ on top of the [data store]({{site.baseurl}}/pages/guide/v{{ page.version }}/06-datastores.html) or the set of data stores which support your Elide-based service. While other JPA-based workflows often encourage writing data models that exactly match the underlying schema of the data store, we propose a strategy of isolation on per-service basis. Namely, we recommend creating a data model that only supports precisely the bits of data you need from your underlying schema. Often times there will be no distinction when first building your systems. However, as your systems scale and you develop multiple services with overlapping data store requirements, isolation often serves as an effective tool to **reduce interdependency** among services and **maximize the separation of concern**. Overall, while models can correspond to your underlying data store schema as a one-to-one representation, it's not always strictly necessary and sometimes even undesirable. As an example, let's consider a situation where you have two Elide-based microservices: one for your application backend and another for authentication (suppose account creation is performed out-of-band for this example). Assuming both of these rely on a common data store, they'll both likely want to recognize the same underlying _User_ table. However, it's quite likely that the authentication service will only ever require information about user **credentials** and the application service will likely only ever need user **metadata**. More concretely, you could have a system that looks like the following: diff --git a/pages/guide/v6/13-swagger.md b/pages/guide/v6/13-swagger.md index 6357e8ab..6fcd4830 100644 --- a/pages/guide/v6/13-swagger.md +++ b/pages/guide/v6/13-swagger.md @@ -202,7 +202,7 @@ String jsonOutput = SwaggerBuilder.getDocument(document); #### Configure JAX-RS Endpoint -Or you can use the Swagger document directly to configure the [provided JAX-RS Endpoint](https://github.com/yahoo/elide/blob/master/elide-swagger/src/main/java/com/yahoo/elide/contrib/swagger/resources/DocEndpoint.java): +Or you can use the Swagger document directly to configure the [provided JAX-RS Endpoint](https://github.com/yahoo/elide/blob/master/elide-swagger/src/main/java/com/yahoo/elide/swagger/resources/DocEndpoint.java): ```java Map swaggerDocs = new HashMap<>();