Swagger AEM is an OpenAPI specification for Adobe Experience Manager (AEM) API.
This specification is used to generate client libraries for Ruby, Python, node.js, and Java using Swagger Code Generator.
Learn more about Swagger AEM:
- Generated Clients
- Development
- Testing
- Frequently Asked Questions
- Versions History
- Contribution
- Presentations
Swagger AEM is part of AEM OpenCloud platform but it can be used as a stand-alone.
Language | Package | Getting Started | Status |
---|---|---|---|
Ruby | swagger_aem |
README CHANGELOG | |
Python | swaggeraem |
README CHANGELOG | |
Java | swaggeraem4j |
README CHANGELOG | |
JavaScript | Work in progress | README CHANGELOG |
To run build targets using swagger-codegen
in your path:
make <target>
If you want to use a custom swagger-codegen-cli.jar
:
SWAGGER_CODEGEN_CLI_JAR=/path/to/swagger-codegen-cli.jar make <target>
Unit tests are generated by swagger-codegen
along with the client code.
Integration tests are part of Swagger AEM and require an AEM instance running on port 4502 with Shine Solutions AEM Health Check package installed.
- Q: Why does each OSGI config need to be declared as a single operation in the OpenAPI spec?
A: There are two reasons. The first one is to explicitly define which parameters are relevant for which OSGI config, which won't be clear when we have one operation for all OSGI configs with all parameters declared within that operation. The second one is to manage the usability of the generated code. A single operation will translate to a single method with all parameters supported, which is fine in generated Ruby client because it supports optional hash, but it's a problem with generated Java client because all parameters will be declared within the method signature where caller will have to pass innull
s for the parameters that aren't relevant for the OSGI config being processed, on top of the risk of hitting maximum number of 255 parameters per method (as per JVM Specification for Java SE 11).
Since swagger-aem contains multiple languages, add a [ruby|python|javascript|java]
prefix to language-specific commits, this will help with filtering full commits log.
Tagging should also be prefixed with:
api
when the release is for the OpenAPI specification, e.g.api-1.0.0
ruby|python|javascript|java
when the release is for the generated client, e.g.ruby-0.9.2
,python-0.9.0