It is so confusing, can someone help me demystify?
Does MuleSoft support OpenAPI 3.x.x specification as of today? Also what is this RAML 1.0 specification? Do we really care about RAML specs when dealing with MuleSoft?
The OpenAPI Specification (OAS), originally known as the Swagger Specification, is a specification for machine-readable interface files for describing, producing, consuming, and visualizing RESTful web services.
RAML, API Blueprint are same kind of IDL for REST API.
MuleSoft have a product called Anypoint Platform API designer that can help design only RAML API specifications, so it does NOT support OAS 3.0.0.
However, the product support the OAS 2.0. You can import an OAS ZIP or JSON file from your file system or from a URL. The importation converts the OAS to RAML. Basically, it is OAS to RAML converter.
The OAS 3.x support has been released in MuleSoft in API Designer, Anypoint Exchange, and Anypoint API Community Manager since June 26, 2020.
You still can not use OAS 3.x in the implementation and manually have to convert it to RAML or OAS 2.0. But API consumers can still discover, learn, and consume the APIs seamlessly, regardless of the specification language.
More in this link. https://docs.mulesoft.com/release-notes/platform/oas3
Here you go. there is a latest release on OAS3.1.0 support in mule4.
Anypoint studio, designer, exchange supports new features such as callbacks and links.
If you want to migrate mule3 to mule4 use mule migration assistant.
https://docs.mulesoft.com/release-notes/platform/oas3
Please have a look at it.
Related
I am lost in dependencies and tools:
I previously use the following tool to generate code for my swagger webservices.
swagger-codegen-cli
https://mvnrepository.com/artifact/io.swagger.codegen.v3/swagger-codegen-cli/3.0.13
https://github.com/swagger-api/swagger-codegen
Then I noticed the following tool, and thought this was a successor:
openapi tools generator
https://github.com/OpenAPITools/openapi-generator
https://openapi-generator.tech/docs/installation.html
But the code that is generated uses different annotations and seems older.
Could somebody tell me, are these 2 tools related to eachother and which one is the more recent version?
From the OpenAPI Generator FAQs
What is the difference between Swagger Codegen and OpenAPI Generator?
Swagger Codegen is driven by SmartBear while OpenAPI Generator is
driven by the community. More than 40 top contributors and template
creators of Swagger Codegen have joined OpenAPI Generator as the
founding team members. For more details, see the Fork Q&A.
Swagger is a trademark owned by SmartBear and the use of the term
"Swagger" in this project is for demo (reference) purposes only.
One way to compare open-source projects is using https://openhub.net.
e.g. OpenAPI Generator vs Swagger Codegen.
From the activity and community graphs, openapi-generator seems to be a lot more active.
Its seems that openapi is in a messy state currently. I'm also confused on which generator to use... And I want to write a custom generator.
GRPC is in a much better state. Every generator is a plugin and the core is well maintained, are the community is not forking.
Update:
Our company has agreed to keep using OpenAPI. We're now using the new OpenSource variant of OpenAPI: openapi-generator.tech/
We've extended the python generators to tweak the generated code.
We're also using client generators in TypeScript and considering Kotlin and Swift for our mobile apps.
In the end it works well. If you're not ready to go binary with GRPC, OpenAPI is a nice alternative. It does requires a bit more, my experience with GRPC is that its a no-brains solution. "It Just Works".
But your miles may vary.
Can Olingo v2.x and v4.x run in the same Java webapp side-by-side?
I know some libraries like Jackson 1.x and 2.x support this: a project can depend on both Jackson 1.x and 2.x, without conflicts
I'm using just Olingo 4, but as far as I know v2 and v4 are growing independently. I don't think it would be a problem to use them both.
And, in the worst scenario, you can use Olingo 2 for OData 2 and SDL OData Frameworks for OData 4, which are totally different libraries.
That should work. I've encapsulated olingo-odata2 and olingo-odata4 in their own Spring Framework based REST controllers and provide services side by side.
In the Swagger UI, the model/model schema are documented in the Parameters section. When I import the same documentation into the Azure API Management portal, parameters with .NET data types are documented but the complex object/model/model schema in the request body loses its documentation.
I saw an update for Model Schema support Azure API Management adds support for Swagger model schemas.
But it did not work when I tried it in the API Portal.
Do anyone know how to import the Model Schema Documentation into the Azure API Management Portal?
Is this update available in New Portal only? And if so when will API management be available in New Portal?
Note: I am using Swagger 2.0 documentation from Swashbuckle in Visual Studio 2013.
Model schemas are imported if they are in the Swagger file. If that's not the case your saw, can you please send your Swagger file to apimgmt at microsoft dotcom so that we can take a look at the file.
I was able to repro this issue and have fixed it. Hopefully, I will be able to get the fix in the next release.
I tried very hard to find and could not.
I need OAuth 1.0 since I need to use intuit QB which not support oauth 2.0 yet.
thanks!
I had the same struggle the past few days in finding an implementation for .NET Core that supports OAuth 1.0. The library from Chilkat may be the only one out there. Not sure if the OAuth API inside the library requires the commercial license or not.
https://www.chilkatsoft.com/refdoc/csOAuth1Ref.html
https://www.chilkatsoft.com/dotnet-core.asp
Another solid option is to use the portable version RestSharp which has a built-in OAuth1Authenticator: https://www.myget.org/feed/restsharp-portable/package/nuget/FubarCoder.RestSharp.Portable.OAuth1
I used OAuth.DotNetCore for OAuth 1.0 with .Net Core 2.1, it worked fine.
https://www.nuget.org/packages/OAuth.DotNetCore/
What are the criteria to decide whether to write WSDL's after the 1.1 or the 2.0 specification?
Should one use by default 1.1 or 2.0?
It's hard to answer without any additional info.
While WSDL 1.1 is not an official standard, it is a de-facto standard, so many tools support it. WSDL 2.0 has little support from tools:
Apache Woden - no recent development, problems with WSDL 2.0 generation.
EasyWSDL - problems with parsing extensions, looks like version 3.0 is in development.
tinyWSDL - some JAXB limitations and bugs keeps it in beta.
Note that WSDL 2.0 specification differs from WSDL2.xsd, so not all rules may be validated or reflected in XML Schema.
Nothing prevents you from using both. Woden and tinyWSDL have converters WSDL 1.1 -> 2.0. easyWSDL not sure (2.0 uses the same model for both 1.1/2.0, but could it be used for conversion?).
In any case you can convert 95% of your WSDL 1.1 into WSDL 2.0.
Cheers,
D.