@lessless can you elaborate on what you’re looking for?
OpenApiSpex
doesn’t support reading external JSON/YAML files, but there is some flexibility in organizing the Elixir code.
@lessless can you elaborate on what you’re looking for?
OpenApiSpex
doesn’t support reading external JSON/YAML files, but there is some flexibility in organizing the Elixir code.
Plug application example clarified it. I thought about extracting specs in separate .ex
files and importing them later on, but having a module per http action is even better.
Version 3.2.0 released.
Lots of internal improvements and some new features thanks to the wonderful contributors, particularly @moxley and the team at Ghost Group / Weedmaps.
Highlights:
SwaggerUI
with Plug.CSRFProtection
See the changelog for more details.
Version 3.4.0 released.
This version is required when using Phoenix 1.4.7+ and the OpenApiSpex.Paths.from_router/1
function.
Highlights:
OpenApi
document and the Info
structsServer.from_endpoint
now uses the Phoenix API instead of the endpoint config to determine the URLamazing lib! thanks @mbuhot!
I loved the idea that the controller tests are guaranteeing the API protocol, so when our mobile/web devs (or us) access the swaggerui, they will see a guaranteed documentation
In the example the api data is returned by show_operation
which is just a function, so you can pull the %Operation{}
data from anywhere.
Version 3.5.0 is released!
This version has a lot of changes from the last several months. Highlights:
Thank you to @mbuhot for letting me manage the release.
Version 3.6.0 is released!
This release include some enhancements and important bug fixes:
%Schema{}
(#193)Is there an example for setting up authentication in the operations? I didn’t find in the example app. Thanks.
Sorry no sample code for security yet, a PR to the example app would be most welcome!
It should be a matter of declaring the securitySchemes
within the components
section of your API spec, then referencing the schemes by name within each Operation
.
https://swagger.io/docs/specification/authentication/
Are you using something simple like API keys or more complex like OpenIdConnect?
Thanks for getting back. to me, I am using simple authorization with a bearer token, the same level of simplicity of API key. I got that working and I can open a PR with some documentation updates to guide other users as the example app does not require authorization.
Version 3.7.0 is released!
This release include some enhancements and important bug fixes:
Hello,
I am wondering if it is possible to create a flag that uses the supportedSubmitMethods
on the network configuration of SwaggerUI (https://github.com/swagger-api/swagger-ui/blob/master/docs/usage/configuration.md#user-content-supportedsubmitmethods) to disable the Try it Out feature for certain methods?
Great product btw!
I think we can add support for the configUrl
option, allowing users to have a JSON file in priv/static
that can be used to configure most of the swaggerUI options with needing to add flags in OpenApiSpex.
Interested in sending a PR? There’s a similar feature in the PhoenixSwagger SwaggerUI Plug that can be used for reference
Thank you!
Version 3.8.0 is released!
This release comes with a couple of new features alongs with lots of enhancements and fixes:
false
to @doc
annotation to skip the warning. (#236)security
@doc
string attribute on operations (#251)Reference
to be used for directly in the parameters
definition (#258)Reference
to be used for an Operation’s request body (#260)@doc
specs (#238)components.parameter
missing s
in CastParamters (#257)As always, a huge thank you to all the contributors and maintainers for keeping the project going
Feel free to try out the swaggerui-config
branch: https://github.com/open-api-spex/open_api_spex/pull/271
You can configure the supportedSubmitMethods
(any many other options) like:
get "/swaggerui", OpenApiSpex.Plug.SwaggerUI,
path: "/api/openapi",
supported_submit_methods: [:get, :post],
default_model_expand_depth: 3,
display_operation_id: true
Thanks a lot for the latest release and also for the whole library. It’s really useful for me.
One thing I am not sure how to do is something like “polymorphic” schemas. This could be used for example with an endpoint returning 409
(conflict) with multiple meanings.
For example for one endpoint it means email is already registered or email is already invited. For some other endpoint 409
could mean some other options. I know I can create new Error.Conflict*
schema for each endpoint and use the enum: [ ... ]
atribute, but this could become quite non-DRY after a while.
I would really like something like
409 => {"Conflict", "application/json", Api.Schema.Conflict.new("email_already_registered", "email_already_used")
with the schema defined like this:
defmodule Api.Schema.Conflict do
require OpenApiSpex
alias OpenApiSpex.Schema
def new(enum) do
OpenApiSpex.schema(%{
title: "Error.Conflict",
type: :object,
properties: %{
error: %Schema{
type: :object,
properties: %{
name: %Schema{
type: :string,
enum: enum,
required: true
},
message: %Schema{type: :string}
}
}
}
})
end
end
Is it possible or am trying to use a completely wrong approach?
Interesting! How about if you construct the %Schema{}
struct directly in new
?
defmodule Api.Schema.Conflict do
require OpenApiSpex
alias OpenApiSpex.Schema
def new(enum) do
%Schema{
title: "Error.Conflict",
type: :object,
properties: %{
error: %Schema{
type: :object,
properties: %{
name: %Schema{
type: :string,
enum: enum,
required: true
},
message: %Schema{type: :string}
}
}
}
}
end
end
It won’t define a struct for you, but it might be fine for a simple response schema?