diff --git a/crnk-documentation/src/docs/asciidoc/resource.adoc b/crnk-documentation/src/docs/asciidoc/resource.adoc
index 466bcb851..ecf72f340 100644
--- a/crnk-documentation/src/docs/asciidoc/resource.adoc
+++ b/crnk-documentation/src/docs/asciidoc/resource.adoc
@@ -480,15 +480,38 @@ See http://jsonapi.org/format/#document-links for more information about linking
}
----
-By default links are serialized as:
+Links can be represented either as either simple String:
+----
+"http://example.com/articles/1/relationships/comments",
+----
+
+or as structured objects of type `Link` with
+`href`, `rel`, `anchor`, `params`, `describedBy` and `meta` fields:
+
+----
+"links": {
+ "self": "http://example.com/articles/1/relationships/comments",
+ "related": {
+ "href": "http://example.com/articles/1/comments",
+ "describedby": "http://example.com/schemas/article-comments",
+ "meta": {
+ "count": 10
+ }
+ }
+ }
+}
+----
+
+`LinksInformation` objects can hold either type. With `DefaultLink` there is a default implementation
+of `Link` available. By default simple strings will be serialized as such:
----
"links": {
"self": "http://example.com/posts"
}
----
-With `crnk.config.serialize.object.links=true` links get serialized as:
+This can be changed by setting the property `crnk.config.serialize.object.links=true`:
----
"links": {
diff --git a/crnk-documentation/src/docs/releases/latest/info.html b/crnk-documentation/src/docs/releases/latest/info.html
index 9e4b0b3ef..6c4557023 100644
--- a/crnk-documentation/src/docs/releases/latest/info.html
+++ b/crnk-documentation/src/docs/releases/latest/info.html
@@ -1,11 +1,113 @@
+This release provides many incremental improvements over 3.1 together with experimental support for versioning
+and more support for the upcoming JSON:API 1.1.
+
+
Versioning Support (experimental) #238
+
+This release brings experimental support for versioning of resources and fields based on content negotiation. Any resource
+and field can carry a version range to specify its availability. Crnk will disregard any resource and field with a version
+range that does not intersect with the request version. The HTTP Accept header is used to pass along the desired version
+as part of general content negotiation. This has the benefit that URLs remain constant across versions, greatly simplifying
+usability and linking. For a more detailed discussion, see here[https://blog.ploeh.dk/2015/06/22/rest-implies-content-negotiation/].
+An example looks like:
+
+
+@JsonApiResource(type = "versionedTask")
+@JsonApiVersion(max = 5)
+public class VersionedTask {
+
+ public enum CompletionStatus {
+ DONE,
+ OPEN,
+ IN_PROGRESS
+ }
+
+ @JsonApiId
+ private Long id;
+
+ private String name;
+
+ @JsonApiVersion(min = 1, max = 3)
+ private boolean completed;
+
+ @JsonApiVersion(min = 5)
+ @JsonProperty("completed")
+ private CompletionStatus newCompleted;
+
+}
+
+
+
+ For more details have a look here.
+
+
+
+Support for Object-based Links
+
+Links can be represented as either simple string or structured objects with href
, rel
, anchor
,
+params
, describedBy
and meta
. There is a new Link
interface and DefaultLink implementation
+to model such objects. LinksInformation
can now either hold Strings or DefaultLink
. An example looks like:
+
+
+"links": {
+ "self": "http://example.com/articles/1/relationships/comments",
+ "related": {
+ "href": "http://example.com/articles/1/comments",
+ "describedby": "http://example.com/schemas/article-comments",
+ "meta": {
+ "count": 10
+ }
+ }
+}
+
+
+More information can be found in https://jsonapi.org/format/1.1/#document-resource-object-links
+and http://www.crnk.io/releases/latest/documentation/#_jsonapilinksinformation.
+
+Misc Improvements
+
- - Improved logging for relationship inclusion mechanism. Set
io.crnk
to DEBUG to learn more
- about how inclusions are loaded.
-
- - Reenabled Spring Boot 1 support.
- - JSON-based filter parameters fixed to support renaming of attributes with @JsonProperty.
- - When using faceted search, the value map is sorted by total count in descending order.
- - Built-in ExceptionMappers can be overriden by custom ones
- - ExceptionMappers can implement Prioritizable
- - More documentation for ExceptionMappers
-
\ No newline at end of file
+ Improved logging for relationship inclusion mechanism. Set io.crnk
to DEBUG to learn more
+ about how inclusions are loaded.
+
+ Re-enabled Spring Boot 1 support upon request to be maintained a little while longer.
+ JSON-based filter parameters fixed to support renaming of attributes with @JsonProperty.
+ When using faceted search, the value map is sorted by total count in descending order.
+ Built-in ExceptionMappers can be overridden by custom ones by implementing the Prioritizable interface.
+ ExceptionMappers can implement Prioritizable
+ More documentation for ExceptionMappers
+ Meta-model is excluded from OpenAPI generation by default. #625
+ Non-ID fields can no longer be named id
.
+ Bulk support through the BulkResourceRepository interface now supports HTTP DELETE operations.
+ This complements existing support for POST. PATCH has not yet been implemented.
+
+ JPA repositories avoid issuing a count query in some situations where the configured offset, limit and
+ received result sets allow to by-pass it. Greatly improving performance in some situations! Where every bit of
+ performance is essential, the existing "has more" strategy rather than total count may also be of help.
+
+ JAX-RS integration has an improved path handling. There will be some more work to harden this area
+ in the future to account for the different behavior of different frameworks.
+
+ Refinements to the JPA-related documentation. For example,
+ how to implement more advanced use cases where the entity and resource model do not fully match.
+
+
+ Better error message when the parsing of an enum parameter fails.
+
+ The order of attributes is honored in the serialized REST documents. Attributes in the implementation and on the REST layer will have
+ the same order.
+
+ A bug fix when resolving attribute paths from subtypes of a resource #712.
+ Improvements to the Typescript generation for the java.util.Map data type #709
+ The CrnkExceptionMapper uses the JSON:API error fields title
and code
if detail
is not available for better
+ error messages.
+
+ New UrlBuilder interface introduced as public API that allows to customize the construction of URLs out of resource ids and QuerySpecs.
+
+
+
+Acknowledgements
+
+A special thanks to Broad, Ralph, JB, PoffM, Christian, Sebastian,
+Kokogino, duncanportelli, Luka, Gianin, fjf2002, Tomasz, erjaimin for all
+the contributions to make this release happen!
+
diff --git a/crnk-documentation/src/docs/releases/stable/info.html b/crnk-documentation/src/docs/releases/stable/info.html
index b75932967..f1bad35bf 100644
--- a/crnk-documentation/src/docs/releases/stable/info.html
+++ b/crnk-documentation/src/docs/releases/stable/info.html
@@ -1,212 +1,113 @@
-This release provides many incremental improvements to 3.0 while introducing three major new features.
+This release provides many incremental improvements over 3.1 together with experimental support for versioning
+and more support for the upcoming JSON:API 1.1.
+Versioning Support (experimental) #238
-OpenAPI Support (experimental)
-
-Experimental support for OpenAPI is now available as extension to the Crnk generator. It will generate
-an OpenAPI schema out of any Crnk endpoint by inspecting the implementation and derive a schema. An
-example setup looks like:
+This release brings experimental support for versioning of resources and fields based on content negotiation. Any resource
+and field can carry a version range to specify its availability. Crnk will disregard any resource and field with a version
+range that does not intersect with the request version. The HTTP Accept header is used to pass along the desired version
+as part of general content negotiation. This has the benefit that URLs remain constant across versions, greatly simplifying
+usability and linking. For a more detailed discussion, see here[https://blog.ploeh.dk/2015/06/22/rest-implies-content-negotiation/].
+An example looks like:
-buildscript {
- dependencies {
- classpath "io.crnk:crnk-gen-gradle:${version}"
+@JsonApiResource(type = "versionedTask")
+@JsonApiVersion(max = 5)
+public class VersionedTask {
+
+ public enum CompletionStatus {
+ DONE,
+ OPEN,
+ IN_PROGRESS
}
-}
-
-apply plugin: 'crnk-gen'
- crnkGen {
- runtime {
- configuration = 'openapiGenRuntime'
- }
-
- // fork generation into new process to have clean environment
- forked = true
- // specify the package to look for resources
- resourcePackages = ['io.crnk.test']
+ @JsonApiId
+ private Long id;
- openapi {
- // enable OpenAPI generation within Gradle plugin
- enabled = true
+ private String name;
- // specify name of openapi template in the build dir to merge onto
- templateName = "openapi-template.yml"
+ @JsonApiVersion(min = 1, max = 3)
+ private boolean completed;
- // specify name of API to display in the generated OpenAPI file
- projectName = "Generated Title"
+ @JsonApiVersion(min = 5)
+ @JsonProperty("completed")
+ private CompletionStatus newCompleted;
- // specify version of the API to display in the generated OpenAPI file
- projectVersion = "0.1.0"
-
- // specify name of openapi template in the build dir to merge onto
- projectDescription = "A generated description of the API."
-
- // specify location of generated sources
- genDir = file('src/resources')
- }
- }
}
-crnkGen.init()
-Fore more information see here.
-Have a look at the GitHub
- tickets
-for the future roadmap.
+
+ For more details have a look here.
+
-Bulk Repositories (experimental)
+Support for Object-based Links
-There is a new experimental BulkResourceRepository that closely resembles ResourceRepository but
-takes multiple resources as arguments. This give the repository the possibility to optimize
-bulk mutations of multiple resources, like sharing a database transaction.
-
-Currently only POST is implemented, not PATCH and DELETE yet! More information can be
-found here.
-In future releases this will be aligned with support for the upcoming JSON:API 1.1 specification.
+Links can be represented as either simple string or structured objects with href
, rel
, anchor
,
+params
, describedBy
and meta
. There is a new Link
interface and DefaultLink implementation
+to model such objects. LinksInformation
can now either hold Strings or DefaultLink
. An example looks like:
-public class BulkInMemoryRepository implements BulkResourceRepository<Task, Long> {
-
- @Override
- public <S extends T> List<S> create(List<S> resources) {
- ...
- }
-
- ...
+"links": {
+ "self": "http://example.com/articles/1/relationships/comments",
+ "related": {
+ "href": "http://example.com/articles/1/comments",
+ "describedby": "http://example.com/schemas/article-comments",
+ "meta": {
+ "count": 10
+ }
+ }
}
+More information can be found in https://jsonapi.org/format/1.1/#document-resource-object-links
+and http://www.crnk.io/releases/latest/documentation/#_jsonapilinksinformation.
-TestKit
-
-There is a new project io.crnk:crnk-testkit to facilitate testing of JSON:API based endpoints.
-As first contribution there is a RandomWalkLinkChecker
:
+Misc Improvements
-
-CrnkClient client = ...
-HttpAdapter httpAdapter = client.getHttpAdapter();
-
-RandomWalkLinkChecker linkChecker = new RandomWalkLinkChecker(httpAdapter);
-linkChecker.setWalkLength(100);
-linkChecker.addStartUrl(...)
-
-linkChecker.performCheck();
-
-
-It performs a random walk on an API endpoint by following the links as specified by JSON:API. It
-will verify that each links provides a valid 2xx response code. By having a sufficiently long walk,
-it will ensure that any GET request can be served with high probability. This in turn allows
-developers to focus on testing business functionality, while lower layer REST details like linking get
-verified automatically.
-
-More information and roadmap are available here.
+
+ - Improved logging for relationship inclusion mechanism. Set
io.crnk
to DEBUG to learn more
+ about how inclusions are loaded.
+
+ - Re-enabled Spring Boot 1 support upon request to be maintained a little while longer.
+ - JSON-based filter parameters fixed to support renaming of attributes with @JsonProperty.
+ - When using faceted search, the value map is sorted by total count in descending order.
+ - Built-in ExceptionMappers can be overridden by custom ones by implementing the Prioritizable interface.
+ - ExceptionMappers can implement Prioritizable
+ - More documentation for ExceptionMappers
+ - Meta-model is excluded from OpenAPI generation by default. #625
+ - Non-ID fields can no longer be named
id
.
+ - Bulk support through the BulkResourceRepository interface now supports HTTP DELETE operations.
+ This complements existing support for POST. PATCH has not yet been implemented.
+
+ - JPA repositories avoid issuing a count query in some situations where the configured offset, limit and
+ received result sets allow to by-pass it. Greatly improving performance in some situations! Where every bit of
+ performance is essential, the existing "has more" strategy rather than total count may also be of help.
+
+ - JAX-RS integration has an improved path handling. There will be some more work to harden this area
+ in the future to account for the different behavior of different frameworks.
+
+ - Refinements to the JPA-related documentation. For example,
+ how to implement more advanced use cases where the entity and resource model do not fully match.
+
+ -
+ Better error message when the parsing of an enum parameter fails.
+
+ - The order of attributes is honored in the serialized REST documents. Attributes in the implementation and on the REST layer will have
+ the same order.
+
+ - A bug fix when resolving attribute paths from subtypes of a resource #712.
+ - Improvements to the Typescript generation for the java.util.Map data type #709
+ - The CrnkExceptionMapper uses the JSON:API error fields
title
and code
if detail
is not available for better
+ error messages.
+
+ - New UrlBuilder interface introduced as public API that allows to customize the construction of URLs out of resource ids and QuerySpecs.
+
-Minor Improvements
+Acknowledgements
-
- - There is a new documentation section about in-memory repositories and their
- use for small data sets, testing and mocking.
-
- -
- CrnkClient verifies the resourceClass of passed QuerySpec objects to ensure they match with the invoked
- repositories. Watch out for this change, because it was easy to get it wrong and may never got noticed.
- The change makes no difference for empty QuerySpecs. But filtering, sorting and paging requests
- get ignored with in-proper typing. The following example will now cause an exception:
-
-
-CrnkClient client = ...
-ResourceRepository<Task,Long>repository = client.getRepositoryForType(Task.class);
-repository.findAll(new QuerySpec(Project.class));
-
-
- - Attributes and relationships can no longer be named
meta
and links
to
- have a clear distinction to the JSON:API data structures.
-
- - Sorting for JPA entities with @EmbeddedId has been improved. For details see 603.
-
- -
- Self URLs can now be written manually by letting resources hold link objects implementing
- SelfLinksInformation. The Crnk engine will no longer interfere if a self link is already
- set for a resource or list.
-
-
-@JsonApiResource(type = "project")
-public class Project {
-
- @JsonApiLinksInformation
- private DefaultSelfLinksInformation links = new DefaultSelfLinksInformation();
-
- ...
-}
-
-
- -
- @JsonProperty handling is fixed for nested resource. This means the relationships between
- parent and child can also be renamed.
-
- -
- CrnkClient makes use of nested URLs to access nested resources, e.g.
-
/api/project/{projectId}/tasks/{taskId}
.
-
- - @JsonApiField.sortable and @JsonApiField.filterable allow to disable sorting and filtering for a field.
- A 400 BAD_REQUEST will be returned in case of a violation has been detected. See
- here.
-
- -
- HomeModule will add links to JSON:API responses if there are resources with overlapping paths, such as
-
/api/tasks
and /api/tasks/history
.
-
- - HomeModule supports the same exception response format as any other JSON:API response.
- - An example for @JsonAnyGetter and @JsonAnySetter has been added to the example application to showcase
- the use of more dynamic resources, see
- PersonEntity
-
- -
- DataRoom logging has been refined to log with WARN if access to a resource is prohibited.
- HTTP errors continue to make use of
403 FORBIDDEN
.
-
- -
- JPA repositories are aware of @JsonApiRelationId annotations and optimize
- sorting and filtering accordingly. If the id of a relationship is filtered or sorted, Crnk rather
- makes direct use of the foreign key rather than joining to the foreign table.
-
- -
- JPA repositories make use of LEFT join when sorting a column on a related entity. This prevents
- the resources from getting omitted if they do not have such a related entity.
-
- - Nested repositories can now span multiple levels, such as
/api/project/{projectId}/tasks/{taskId}/items/{itemId}
-
- -
- Repositories from CrnkClient make use of
@JsonApiExposed(false)
. It allows there
- use on the server-side to consume other services without exposing the repositories again.
- When returning resources obtained from such a repository, they will maintain proper linking
- to the original service as long a the resources carry a links object implementing
- SelfLinksInformation. For an example see
- spring-boot-microservice-example
-
- -
- CrnkClient can be configured with a custom ObjectMapper using
CrnkClient.setObjectMapper(...)
.
-
- -
- ResourceIdentifier can be used together with @JsonApiRelationId do not only hold the ID, but also
- the type of the relationship. Useful when inheritance is involved to directly address the proper subtype.
-
- -
-
ResourceTypeHolder
interfaces allows a resource to hold its resource type. This can proof
- useful in more dynamic settings where inheritance is involved and a repository likes to manipulate
- the type of its resources without having to work with strongly-typed resource classes. Together
- with @JsonAnyGetter and @JsonAnySetter it allows for highly dynamic, non-compile-time repository
- implementations similar but simpler than the direct use of the Resource
class.
- For information is available in the
- documentation.
-
-
+A special thanks to MacLeod Broad, Ralph Marchildon, JB, PoffM, Christian Gendreau, Sebastian Wyrazik,
+Kokogino, duncanportelli, Luka Lodrant, Gianin Basler, fjf2002, Tomasz Staniaszek, erjaimin for all
+the contributions to make this release happen!
diff --git a/crnk-documentation/src/docs/releases/v3.2/info.html b/crnk-documentation/src/docs/releases/v3.2/info.html
new file mode 100644
index 000000000..f1bad35bf
--- /dev/null
+++ b/crnk-documentation/src/docs/releases/v3.2/info.html
@@ -0,0 +1,113 @@
+This release provides many incremental improvements over 3.1 together with experimental support for versioning
+and more support for the upcoming JSON:API 1.1.
+
+Versioning Support (experimental) #238
+
+This release brings experimental support for versioning of resources and fields based on content negotiation. Any resource
+and field can carry a version range to specify its availability. Crnk will disregard any resource and field with a version
+range that does not intersect with the request version. The HTTP Accept header is used to pass along the desired version
+as part of general content negotiation. This has the benefit that URLs remain constant across versions, greatly simplifying
+usability and linking. For a more detailed discussion, see here[https://blog.ploeh.dk/2015/06/22/rest-implies-content-negotiation/].
+An example looks like:
+
+
+@JsonApiResource(type = "versionedTask")
+@JsonApiVersion(max = 5)
+public class VersionedTask {
+
+ public enum CompletionStatus {
+ DONE,
+ OPEN,
+ IN_PROGRESS
+ }
+
+ @JsonApiId
+ private Long id;
+
+ private String name;
+
+ @JsonApiVersion(min = 1, max = 3)
+ private boolean completed;
+
+ @JsonApiVersion(min = 5)
+ @JsonProperty("completed")
+ private CompletionStatus newCompleted;
+
+}
+
+
+
+ For more details have a look here.
+
+
+
+Support for Object-based Links
+
+Links can be represented as either simple string or structured objects with href
, rel
, anchor
,
+params
, describedBy
and meta
. There is a new Link
interface and DefaultLink implementation
+to model such objects. LinksInformation
can now either hold Strings or DefaultLink
. An example looks like:
+
+
+"links": {
+ "self": "http://example.com/articles/1/relationships/comments",
+ "related": {
+ "href": "http://example.com/articles/1/comments",
+ "describedby": "http://example.com/schemas/article-comments",
+ "meta": {
+ "count": 10
+ }
+ }
+}
+
+
+More information can be found in https://jsonapi.org/format/1.1/#document-resource-object-links
+and http://www.crnk.io/releases/latest/documentation/#_jsonapilinksinformation.
+
+Misc Improvements
+
+
+ - Improved logging for relationship inclusion mechanism. Set
io.crnk
to DEBUG to learn more
+ about how inclusions are loaded.
+
+ - Re-enabled Spring Boot 1 support upon request to be maintained a little while longer.
+ - JSON-based filter parameters fixed to support renaming of attributes with @JsonProperty.
+ - When using faceted search, the value map is sorted by total count in descending order.
+ - Built-in ExceptionMappers can be overridden by custom ones by implementing the Prioritizable interface.
+ - ExceptionMappers can implement Prioritizable
+ - More documentation for ExceptionMappers
+ - Meta-model is excluded from OpenAPI generation by default. #625
+ - Non-ID fields can no longer be named
id
.
+ - Bulk support through the BulkResourceRepository interface now supports HTTP DELETE operations.
+ This complements existing support for POST. PATCH has not yet been implemented.
+
+ - JPA repositories avoid issuing a count query in some situations where the configured offset, limit and
+ received result sets allow to by-pass it. Greatly improving performance in some situations! Where every bit of
+ performance is essential, the existing "has more" strategy rather than total count may also be of help.
+
+ - JAX-RS integration has an improved path handling. There will be some more work to harden this area
+ in the future to account for the different behavior of different frameworks.
+
+ - Refinements to the JPA-related documentation. For example,
+ how to implement more advanced use cases where the entity and resource model do not fully match.
+
+ -
+ Better error message when the parsing of an enum parameter fails.
+
+ - The order of attributes is honored in the serialized REST documents. Attributes in the implementation and on the REST layer will have
+ the same order.
+
+ - A bug fix when resolving attribute paths from subtypes of a resource #712.
+ - Improvements to the Typescript generation for the java.util.Map data type #709
+ - The CrnkExceptionMapper uses the JSON:API error fields
title
and code
if detail
is not available for better
+ error messages.
+
+ - New UrlBuilder interface introduced as public API that allows to customize the construction of URLs out of resource ids and QuerySpecs.
+
+
+
+Acknowledgements
+
+A special thanks to MacLeod Broad, Ralph Marchildon, JB, PoffM, Christian Gendreau, Sebastian Wyrazik,
+Kokogino, duncanportelli, Luka Lodrant, Gianin Basler, fjf2002, Tomasz Staniaszek, erjaimin for all
+the contributions to make this release happen!
+