Creating RESTful APIs with Spring Boot is a straightforward process, making it a popular choice for a variety of applications, from UI to batch processing. The same API created can be used anywhere, whether it’s called from a UI application or batch applications. However, testing these APIs to ensure they work correctly can be challenging. In this article, I’ll introduce …
I am assisting a client that is migrating from a monolithic legacy application to a modern Microservice stack with Spring REST. We are helping to implement Swagger UI to provide both a front-end API UI, as well as to provide a level of documentation at the same time. This implementation has simultaneously met our project requirements, as well as garnering some positive feedback from our client!
Swagger UI is one of the most popular tools to visually render beautiful, interactive API documentation. In this blog, I’ll use a REST API application to demonstrate some usage of Swagger UI. The source project is available at https://github.com/bingliu2016/spring-boot-rest-swagger2.
In a previous post, we discussed the basics of GraphQL and how it can be a great REST API alternative. In this one, we’ll see how AppSync can be more than just a great API alternative — it gives you a soft landing into the world of GraphQL.
Recall our Game API example? Let’s start with the basic type of a game. Follow along and we can implement a simple schema in AppSync together….
The basic premise of data transfer and involves requesting and receiving lists. This is simplistic, but it gets to the root of why we’ve developed the technologies and best practices to pass data using web services. RESTful APIs have grown to serve the needs of numerous individuals, startups, and enterprise companies across the world. They are useful, productive, and the concepts surrounding them are relatively standardized. If you don’t know how to create one, you can quickly find information building a great API that can grow to fit your needs. That’s when things get complicated…
If you start digging into REST, you’ll realize there’s quite a bit more to throwing lists. There are common threads that many people encounter when developing an API, and you begin to encounter many of the same questions so many others have before, such as: How strictly should you adhere to the principles of REST? How should you handle versioning? Should you bother? How do you want to structure your objects? Are users able to easily figure out what API endpoints are available and how they should be used?
There are many ways approach these. It boils down to communicating the structures that a given endpoint will return or accept. The cascade of questions that results from the choices made here will ripple through from the back-end to the client. The secondary issue is that these questions and choices are not at all uncommon. There are answers to these that follow Best Practices. But there is still plenty of ambiguity involved when attempting to build a flexible API that works well. These are the Commonly Tolerated Situations.
If you hadn’t already guessed, there is a solution that frees us from the dogma of REST and allows us to solve all these issues in a declarative, powerful, and fun way. That solution is GraphQL. In this blog, I’ll provide an introduction to the GraphQL specification with code examples…
If you are heading down the path of a Microservices style of architecture, one tenant you will need to embrace is automation. Many moving parts are introduced with this style of architecture. If successful, your environment will have a plethora of service APIs available that the enterprise can consume for application development and integration.
This means that there must be a way that available API documentation can be discovered. API information needs to be effectively communicated throughout the enterprise that shows where APIs are used, how often APIs are used, and when APIs change. Not having this type of monitoring in place will hinder and possibly cripple the agility benefits that a Microservice style of architecture can bring to the enterprise.
This blog will describe how Swagger/OpenAPI documentation can be applied to a Spring Boot implementation. We will show how API documentation and monitoring can be automatically published to an API documentation portal.
As an example, we introduce a reference Spring Boot API CRUD application (using Spring MVC/Data with Spring Fox) and set up the automatic publishing of API documentation and statistics to documentation portal GrokOla. In the example, we introduce two open source utilities to help and allow published APIs the ability to be searched and notify users when changed….
