I am looking into using the Swashbuckle.AspNetCore v4.0.1 NuGet package in my ASP.Net Core project to generate a SwaggerUI documentation endpoint for my web API that will be used by various teams internal to my company. My API consumes and emits a handful of message bus events and commands that I'd like to include as part of that documentation.
Are there any custom settings in Swashbuckle's middleware that would allow me to document input/output objects not associated with API endpoints?
That the endpoint emits a a service bus event is an internal implementation detail and should not need to be documented.
If you want to provide documentation for an endpoint you can write XML documentation and configure Swashbuckle to expose that documentation using the IncludeXmlComments method.
Microsoft explains how to configure Swagger this way in their Get started with Swashbuckle and ASP.NET Core article.
Related
When should we use API Proxy against API AutoDiscovery. After implementing both, I found AutoDiscovery can also apply policies, analytics which API Gateway does, only thing is I cannot use a different url if using AutoDiscovery. Main advantage of API Proxy would be if my Gateway application and Mule Implementation Project is in different subnet, so if we are my Gateway server is compromised, no one can get to my implementation network.
But if both interface and implementation is in the same network, and purpose is just to call a REST Endpoint, should we not go with API AutoDiscovery.
Problems with Mule API Gateway Proxy
No defined way of Exception Handling, if we are not able to reach the Implementation Server.
No defined way of moving the Proxy Application across environments (CI/CD)
Extra HTTP Hops, can be acceptable if the above 2 issues have a defined way
Mule API AutoDiscovery
Since this is in the Mule Application, standard Exception Handling.
CI/CD is defined as it is the Mule Implementation Project.
No Extra HTTP Hop.
Only thing here is, we cannot change the implementation URL, that is only tightly coupled thing.
Can someone provide insight on when should we go for API Gateway vs AutoDiscovery. Also currently is there a way of doing Exception Handling in API Gateway Project and also CI / CD ?
API Autodiscovery is required if you plan to apply/unapply a policy to a particular endpoint, and/or take advantage of usage statistics in the context of API Platform. Api Autodiscovery is kind of metadata that links a HTTP(s) listener to its counterpart API version on API Manager.
For example:
<api-platform-gw:api id="api.basic.path" apiName="My API" version="1.0.0" flowRef="basic.path">
</api-platform-gw:api>
<flow name="basic.path">
<http:listener config-ref="a.http.config" />
<set-payload value="Endpoint successfully called." />
</flow>
Autogenerated Mule Proxies do have autodiscovery defined. You can also develop your own project and define the corresponding autodiscovery either by using the Studio UI, or handling the XML config directly.
The proxies are mean to be used in the case that your implementation backend is not a Mule application (for example, an existing REST based API hosted in a Tomcat server). You can enrich the logic with custom exception handling among other things on the Mule side. If you'd like better exception handling on the implementation backend, you will have to implement it there.
If your implementation backend is a Mule based application, using a proxy is not required. For most use cases, adding the corresponding autodiscovery element in the configuration file will do the trick.
I have a mule service, named IS, deployed on mule runtime and proxied on API gateway. I'd like to set up different policies to the IS and its proxy service. How can I do it?
My environment:
Mule runtime: 3.7.4
Mule API gateway: 2.1.1
The following are two valid and equally correct solutions that you can choose from, taking into account that your implementation API is a Mule app:
Create an API on API Platform
Solution A:
Configure the autogenerated proxy to use your implementation API URL
Deploy the proxy to a correctly configured API Gateway/Mule runtime
>= v3.8.0
Apply one or more policies to the tracked proxy
Solution B:
Add autodiscovery to your implementation API, using the same API
name and API version name than your already created API on API
Platform
Deploy the impl app to a correctly configured API
Gateway/Mule runtime >= v3.8.0
Apply one or more policies to the tracked implementation app
With solution A, you have to make sure that your implementation app is only accessible by the proxy app (eg with a firewall).
If your implementation API would not be a Mule app, then Solution B would not be possible.
We can create endpoint with a proxy or select Basic endpoint if you create your API outside API Manager, for example, you created the API using Mule ESB. You don’t need a proxy in this case. So policies will be applied to API. For more details go through the link.
https://docs.mulesoft.com/api-manager/setting-up-an-api-proxy
If you're using Mule runtime v3.8.x, and if the service is an HTTP/S listener, you can actually make it auto-discovered in the API Manager and have policies applied directly on it, even if the mule config is not generated using APIkit.
https://docs.mulesoft.com/api-manager/api-auto-discovery
Choose the flow that you want the API Manager to manage and apply policies.
Do note that you will need to have to right entitlement (API Gateway) in the Mule Runtime license and that it has the right Anypoint Platform Client ID/Secret pairs configured in the wrapper.conf. The IDs should be automatically configured if you've added the Mule Runtime server in the Anypoint Runtime Manager.
Here is my solution to apply policy to proxy service:
Create a new API using proxy service's url
Apply policy to API created in step1
Can anyone confirm this is the correct way?
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
I want to use swagger for documenting our RESTful APIs. Our Jersey classes will be consumed from the mule flow. To use swagger for documenting my API I need to use the servlet configuration as mentioned in here - https://github.com/wordnik/swagger-core/wiki/Java-JAXRS-Quickstart
As the Jersey classes are deployed in mule, there is no web.XML.
If you know how to configure swagger with Mule please let me know how to do that. I truly appreciate your feedback and suggestions.
I see two possible options, the latter being the one with the highest chance of success:
Run a Servlet container inside Mule, as demonstrated by the bookstore example provided with the standalone distribution, configuring web.xml as indicated and making sure you're using servlet not http inbound endpoints in your Mule configuration.
Generate at build time a static Swagger configuration using https://github.com/ryankennedy/swagger-jaxrs-doclet and serve it using the static resource message processor from the HTTP transport.
Via Mule I'm going to call a web service. For this what kind of security mechanisms exists. I have referred to the mulesoft.org but I could only find security reference from the point of creating web service based app.
I'm going to call a Restfull WS using JSON
You can create your own cloud connector to consume the API, it is easy to do and it provides you OOTB support for both OAuth 1.0 and 2.0
Here some useful link to get started:
http://www.mulesoft.org/documentation/display/DEVKIT/Your+First+Cloud+Connector
http://www.mulesoft.org/documentation/display/DEVKIT/Authorizing+your+Connector+with+OAuth+2.0