I defined APIs through swagger. For each micro-service, I have a swagger file say micro-service1.yaml.Like that I have around 40 micro-services. Accessing each one is difficult . I want to access all of the through a common URL.How can I achieve the same. Thanks in advance!
One option is to use WebSphere Liberty, since it will aggregate all the APIs running in it and show you them in a single Swagger UI.
However, for 40 micro-services the recommended topology would be to separate them into different WebSphere Collective members (Java w/ Liberty or Node w/ Loopback), where either of them can be inside a Docker container), so you could see all the APIs from the aggregated Collective Controller Swagger UI.
More info in this blog.
Related
The company I work for has a set of microservices that each focuses on a different business capability e.g. payments, transactions, accounts, etc.
We create Open API specs in Swagger Hub (API first design) for each business capability.
Our services are predominantly .NET Core applications running in Kubernetes and we use the Swashbuckle.AspNetCore library to auto generate the Swagger UI from the yml spec (which we copy across manually from Swagger Hub). We've also discussed using .NET attributes to auto-generate the OASs from code, which I'll bring up again below.
Our public clients (native apps & web SPAs) consume multiple business capability APIs and it doesn't really seem optimal to give the public client developers (who are mostly outsourced) multiple OASs i.e. one per business capability. There's also multiple partnerships in the works and I don't think it would look professional to give them 15 different API specs... Ideally we'd have a single API spec for each specific type of consumer (e.g. "Product X public client API", and/or "Product X back-end integration API") that can be broken down into separate categories for each business capability e.g:
Also, some of the operations on a specific business capability might be for different consumers (e.g. public clients or back-end integrations). We could probably work this out by the security scheme (i.e. whether user tokens or M2M tokens are required):
If we continue with the current approach of defining API specs in Swagger Hub for each business capability, we'll need to create an additional aggregated (and partially duplicated) API specs targeted at specific consumers that we would need to continually update manually.
We could switch to defining the aggregated (consumer focused) APIs specs in Swagger Hub, but then we'll need a different way to generate Swagger UI in the microservice applications. Perhaps we could use the attribute based approach mentioned previously to generate the Swagger UI for microservices, but then there's no guarantee it will perfectly align with the aggregated OAS defined in Swagger Hub... before we rush head first down this path, the question is;
Is it possible and are there any tools to merge separate OASs in an automated or semi-automated way (ideally with some basic filtering capabilities i.e. to filter operations based on security tags) so that we don't need to maintain separate aggregated OASs manually? Alternatively, are there any other approaches to solving this problem in a more automated way?
Is it possible and are there any tools to merge separate OASs in an automated or semi-automated way
You can use APIMatic's API spec merge feature to automatically merge your specs and then transform the merged output into OpenAPI's format. Here are the steps:
Structure your directory as follows:
dir\
accounts\
openapi.json
payments\
openapi.json
transactions\
openapi.json
APIMATIC-META.json
A minimalistic metadata configuration file APIMATIC-META.json can look like this to enable merging:
{
"MergeConfiguration": {
"MergedApiName": "Product X",
"MergeApis": true,
"MergeSettings": {
"SkipCodeGenValidation": true
}
}
}
ZIP the directory, upload it and transform it via their website to OpenAPI v3 to get your merged output. Here is a link that provides step by step guide on uploading and performing a transformation manually through the website: https://docs.apimatic.io/manage-apis/api-merging/#transforming-the-zipped-file. Since you are looking for automation, APIMatic has an API to achieve the same too: https://www.apimatic.io/docs/api#/http/api-endpoints/transformation/transform-via-file
ideally with some basic filtering capabilities i.e. to filter operations based on security tags
An OAS API spec you provide in the directory can have a metadata configuration file provided next to it as well which can contain filtering options to take out certain operations. Please see detailed reference document on this here: https://docs.apimatic.io/manage-apis/apimatic-metadata/#filtering-out-parts-of-api-definition-with-metadata
So, your directory structure can then look like the following:
dir\
accounts\
openapi.json
APIMATIC-META.json
payments\
openapi.json
APIMATIC-META.json
transactions\
openapi.json
APIMATIC-META.json
APIMATIC-META.json
The inner metadata files can have a configuration like the following:
{
"KeepEndpointsWithTags": ["public"]
}
When you ZIP the directory, upload and transform it, the output OAS would be the merged output of your "filtered" input OAS files. Note, however, that this filtering isn't based on security level information. It is based on the tags configured at operation level.
i am actually analyzing JIRA for my company regarding the functionalities and the different APIs. At the Atlassian Homepage i found two official provided APIs (JAVA API or JIRA REST API).
My further intentions are to program an interface between my stand-alone application and JIRA. The idea is for instance to control the user-management (add, delete, modify user, etc.), project-management (create project, delete, etc.) and other things from this application. Therefore i need a way to interact with JIRA.
Normally i would avoid the REST API and prefer the JAVA API, because other interfaces are even managed by the JAVA API, but i can't find any examples for connecting, adding or modifying workItems in JIRA. I have just found the java api documentation.
https://developer.atlassian.com/jiradev/jira-apis/java-api-policy-for-jira
Would you suggest only the JAVA REST API or are there any good examples for the JAVA API?
Thanks a lot!
It really depends on what you are trying to achieve. The Java API is mostly used to build Jira plugins, while the REST API is used when you want to integrate external applications.
In your case the normal choice would be the REST API.
I've included swagger bundle in each of my dropwizard service. I was wondering if we can run swagger independently and connect to each service so that user can have a centralised view of all services through one UI.
I'm not aware of something that lets you do that at the moment with Swagger UI specifically, but you might check out DynamicApis.com. They let you host multiple swagger documents and provide some really nice additional value for your APIs as well. They take your Swagger JSON and build you your own API portal out of them. They also have native REST API integration where you can automatically sync up your API to your portal or you can manually upload them.
Here is an example portal they have up to demonstrate how multiple APIs can be hosted and how you see them.
Here is an example of what their documentation for each API looks like. Kind of like Swagger UI++.
You can have multiple swagger instances in a single DW service. The UI, however, does not allow you to point to each of them independently. It's easy enough though to modify index.html to allow the user to select the swagger definitions that you have in the deployment.
I'm working on a webapp running on Tomcat which using spring-data to connect to a neo4j graph in embedded mode.
I would like to use neo4j server instead of the embedded mode and I am looking for some help to be sure about how to do that.
Some of my application services are quite difficult and combine, in a single transaction, the result of several cypher requests in a dto sent back to the user.
First I thought that I have to create a server unmanaged extension and I think I should follow these following steps.
- Keep my webapp with springMVC and spring security to hold and secure users sessions.
- Regroup all my transactional services in a specific jar my-app.jar
- Use Jax-RS to add a REST access point on each of my service of my-app.jar
- use something like spring restTemplate from my spring controller to call services from my-app.jar
First question : is this way of doing things is the good way ?
Second question : I have many spring injection in my services layer. How can I keep them working (how can I add dependencies in the server extension ?
Then I discovered graphAware and I wonder if I should use it instead.
And finally I just read this post http://jexp.de/blog/2014/12/spring-data-neo4j-improving-remoting-performance/ and it seems that I should use
the SpringCypherRestGraphDatabase (as explain in the bold text at the end of the article).
Well, I'm a little bit lost and I would appreciate any help to use neo4j server instead the embedded mode for my application which contain some complexe transactions.
You have a number of options here and you are on the right track with your thinking.
Option 1:
If your use cases are business-logic-heavy, and your question suggests that they are, going the unmanaged extension route is one option.
Essentially, you can then combine the most performant Java API and Cypher (if you wish) to perform your use case. I wouldn't use SDN here by the way, so you have to do your mapping manually, but is there really any mapping? Maybe you just want to execute traversals / Cypher queries for each one of your use cases.
Each use case then exposes a simple REST API, which is consumed by your Spring-powered application running Spring MVC, Spring Security, and all that. You can use the RestTemplate from Spring in your app's Controllers.
To add a twist to all that, you can use the GraphAware Framework to develop the "unmanaged extension" using Spring MVC as well. That would be my preferred option, knowing nothing about your domain/app.
Option 2:
Use the new version of SDN (v4) as Michael suggests. This allows you to run your application with annotated domain objects, Spring MVC, Security, et al. Operations (CRUD and other) are automatically translated to Cypher and sent across the wire to Neo4j running in server mode (no extensions needed). Results are then marshalled back to Java objects.
We're about to release Milestone 1 of SDN v4. It shouldn't take more than a week. That said, it is still going to be a Milestone release, thus not ready for production. A GA release is expected in May (ish).
You can already try SDN v4 yourself. Clone this repo: https://github.com/spring-projects/spring-data-neo4j, make sure you're on the 4.0 branch, and do an mvn clean install on it. Here's a sample app, built using Angular JS and Spring Boot.
Please do get in touch with feedback / questions / problems (best by email info at graphaware dot com). Cheers!
I suggest you wait a bit until SDN4 Milestone 1 comes out (developed by GraphAware) this was written from scratch for Neo4j-Server.
I'm thinking about possible alternatives for our EJB based service layer and wondered if it would make sense to use just the service and database layer of Grails together with the Remoting Plugin or is this using a sledgehammer to crack a nut?
Speaking of the Remoting Plugin: is there a standard way of generating a JAR file, that contains the necessary classes to make a remote call to a Grails service from a non-Spring Java application?
Interesting idea. I don't think it'd be overkill at all. The nice thing is that your service would be very portable across protocols and deployment options (e.g. put a controller layer on top and it's instantly embedded). This gives you the benefits of EJB's (persistence) + the ability to use Groovy and GORM.
FWIW, we're using Grails as our service tier; in come cases we use it embedded (as a plugin), in others we expose the services (via controllers) as JSON or SOAP; I see exposing as RMI as a variation of what we're doing (without the controller layer).