I am using Swashbuckle.ASPNetcore 3.0.0. My Webapi is in .net core 2.0. When I enable the XML documentation feature, both in the project properties and the (2) lines in the startup.cs file, it works fine locally. When I publish to AWS Lambda I get a "interal server error", I have a feeling it has something to do with the .xml file location. I am not sure if it is trying to write that file in the lambda or if that file is static and pushed with the code, when I publish. I would like to use the extra /// information to further enhance the basic swagger doc that gets created without the XML documentation. Can anyone offer up an advise here?
Related
There are only ugly HTML pages as download (HTML, HTML2 and dynamic all ugly), but the site, eg. edited https://app.swaggerhub.com/apis/{user}/{project}/{version}
(and many others!) offers pretty HTML interface... How to download this pretty HTML?
Complete and autonomous HTML code (file or zip of files).
I have a good and valid swagger.yaml or swagger.json file of my API, so another solution is to run a open sourse (plug and play!) tool with my API-description file.
The pretty:
The ugly:
The "pretty interface" on your screenshot is Swagger UI. It's free and open-source. There's a demo at http://petstore.swagger.io, where you can load your own YAML/JSON files from an URL and see how they would be rendered.
To use Swagger UI locally:
Go to https://github.com/swagger-api/swagger-ui and download the repository as ZIP:
Edit the dist\index.html file and change the line
url: "http://petstore.swagger.io/v2/swagger.json",
to the URL of your Swagger .json or .yaml file, e.g.
url: "http://api.mysite.com/swagger.json",
(Optional) Add/change other configuration parameters in the SwaggerUIBundle initialization code in dist\index.html.
Open the dist\index.html file in your browser to preview your API docs.
Note: If the spec does not load or "try it out" does not work, you probably need to enable CORS on the your server. See https://github.com/swagger-api/swagger-ui/blob/master/docs/usage/cors.md and https://enable-cors.org.
Upload the files from the dist folder somewhere to your server - and now you have pretty API docs too!
Alternatively, SwaggerHub (which you mentioned) provides cloud hosting for Swagger specs among other things, and has Swagger UI integrated. You can import your Swagger .json/.yaml files there and have your API docs hosted on SwaggerHub. A free plan is available.
Thanks to #tleyden at swagger-ui/issues for good clues!
Use the index and assets folder of this project, https://github.com/okfn-brasil/swagger-ui-html
I am using Swagger in my .NET Core Web Api project.
I am uploading an Excel file (.xlsx) to the system on my one Controller. But I get Unsupported Media Type error when uploading files because of the Consumes["application/json"] line.
Swagger doesn't work even when Consumes["application/json"] line is removed.
I added the Consumes["application/json"] code because I got a Swagger authorize error.
SOLVED
Adding Consumes["multipart/form-data"] to the top of each function to upload xlsx fixed the problem.
The help for swashbuckle mentions that the ui for Swagger is driven by the generated json schema.
Where is this json file located?
I cannot find it in the folder for my asp.net project
When I actually run the application and navigate to http://localhost:51659/swagger/v1/swagger.json
then I see the json
Where is it on disk? Or is it only in memory?
There is no file generated, it is only on memory.
You might want to read a bit the code:
https://github.com/domaindrivendev/Swashbuckle/blob/master/Swashbuckle.Core/Swagger/SwaggerGenerator.cs
If you need a file you could create an IDocumentFilter to generate one. I have an example here generating a Yaml file:
https://github.com/heldersepu/Swagger-Net-Test/blob/master/Swagger_Test/App_Start/SwaggerConfig.cs#L378
I'm using the ClientInfo class from RESTlet to get the user agent from the browser used by the client.
It works fine but it is kind of out-dated (the new Opera is detected as Chrome, and so on...) so I want manually insert my templates to the agent.properties file. The problem is I don't know where the agent.properties file is. I just have the jar file from RESTlet.
From the link above, it says:
Restlet users has the ability to define their own way to extract data
from the "user-agent" header. It is based on a list of templates
declared in a file called "agent.properties" and located in the
classpath in the sub directory "org/restlet/data".
Anyone knows where is that agent.properties file?
It is in the core restlet library jar (org.restlet) at version 2.2, Sitting in the same package as the ClientInfo class. I have not checked back to 2.0 but I suspect that it remains there.
the github location for the master copy is currently at https://github.com/restlet/restlet-framework-java/blob/master/modules/org.restlet/src/org/restlet/data/agent.properties and I'm sure that a patch to deal with upgraded browser versions, could be welcomed.
I have been working on a BlackBerry application that consumes web services from ColdFusion 7. The Java ME SDK and the Java Wireless Toolkit both require that the generated WSDL be of the document/literal type.
Fortunately, I have input on the web service development so I tried setting 'style="document"' in the cfcomponent tag. This generated a document/literal style WSDL but now wscompile generates the following errors in several places:
Found unknown simple type: javax.xml.soap.SOAPElement
Found unknown simple type: java.util.Calendar
Any ideas why this is happening?
The WSDL does get parsed correctly by the JWSDP tool but the stubs use namespaces that are not available in the J2ME platform. I would have thought ColdFusion WSDL would work more easily with other products in the Java family.
If the service doesn't change much (so the WSDL won't change much) you can save the WSDL as a text file and modify it however you like. My suggestion -- again, assuming the service is more or less finalized -- would be to take the style declaration out of the cfcomponent tag and generate the WSDL, then save it as a plain text file and modify it as necessary to be consumed by the BlackBerry application.
It turns out that the issue was related to the data types of method parameters and return types that was causing the issue. The WSDL was valid and the version of wscompile for J2SE was able to parse it correctly. But due to the reduced API capabilities on the mobile platform, certain data types cannot be parsed with the J2ME version of wscompile.
I did need to keep the 'style="document"' declaration in the cfcomponent tag on the ColdFusion web service since the stub generator for J2ME will only parse document/literal type WSDL files.
http://developers.sun.com/mobility/midp/articles/webservices/ provides a reference for the data types supported in JAX-RPC for Java ME.