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.
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.
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.
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.
.NET Core/Standard 2.0 now lets you reference old .NET Framework libraries. You can install them via NuGet, and the code will build. This works within limits though:
"The supported scenario is referencing a .NET Framework library that happens to only use types within the .NET Standard API set." -- Announcing .NET Core 2.0
When using Topshelf from a .NET Core 2.0 application, I get the following exception:
There seems to be a dependency on System.ServiceProcess.ServiceAccount that is not satisfied. Is this dependency available within the .NET Standard 2.0 spec at all? If not, is there any other way I can get this to work?
TopShelf does not work on .NET Core 2.0 because it is missing some other fundamental APIs as well (most prominent one would be ServiceBase). Some missing types are being developed as NuGet packages for the 2.1 timeframe but this does not mean that TopShelf is instantly going to work. You can follow TopShelf's GitHub issue for .NET Core support for details and updates and even some replacement libraries for basic functionality if you must run on .NET Core until TopShelf will be able to work on .NET Core (basis of which I have written).
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/