Adding more modifications at README.md file level

README.md

@@ -8,7 +8,31 @@ The root of this repository contains multiple Spring Boot projects that sever di
 
 
 
+    So let’s start with the famous question **Swagger** vs **OpenAPI**:
 
+> Although the terms once referred to the same thing, they can no longer be used interchangeably…even though some people still do. In 2021, **OpenAPI refers to the industry-standard specification for RESTful API design. Swagger refers to a set of SmartBear tools**. — [https://nordicapis.com/](https://nordicapis.com/whats-the-difference-between-swagger-and-openapi/#:~:text=Although%20the%20terms%20once%20referred,a%20set%20of%20SmartBear%20tools)
+
+
+
+    To better understand this kind of political things I like to create timelines, so I made this timelines based on my weeks of research (if something is wrong please feel free to comment bellow as it helps us all to publish articles/tutorial/etc. that are more useful and true to the meaning)
+
+
+
+- Swagger is a language-agnostic specification, meaning that it can be used with any programming language
+- Swagger is a RESTful API specification, meaning that it can be used to document APIs that follow the REST architectural style
+- Swagger is not a replacement for documentation, meaning that it should be used in addition to other forms of documentation such as user manuals and tutorials
+
+
+
+I divide this repository made for the medium article in the following projects:
+
+Project: [SwaggerApiInfoExample](https://github.com/Kanames/SpringBoot-SwaggerExamples/tree/main/SwaggerApiInfoExample "SwaggerApiInfoExample")
+
+Project: [SwaggerDocketAdvancedDetailsExample](https://github.com/Kanames/SpringBoot-SwaggerExamples/tree/main/SwaggerDocketAdvancedDetailsExample "SwaggerDocketAdvancedDetailsExample")
+
+Project: [SwaggerGroupingExample](https://github.com/Kanames/SpringBoot-SwaggerExamples/tree/main/SwaggerGroupingExample "SwaggerGroupingExample")
+
+Project: [SwaggerGroupingUsingTagsExample](https://github.com/Kanames/SpringBoot-SwaggerExamples/tree/main/SwaggerGroupingUsingTagsExample "SwaggerGroupingUsingTagsExample")
 
 
 

SwaggerApiInfoExample/README.md

@@ -0,0 +1,37 @@
+# Swagger API Info Example
+
+In this repositoryI am going to show how to add ApiInfo object in your Docket so that you will have a more professional look on your Swagger UI.
+
+My medium post here: https://medium.com/p/ef2ba65ebb86
+
+# Getting Started
+
+    ApiInfo is the object that allows you as a developer to add Contact information, descriptions of the API, terms of use, and other information that are less important from an implementation point of view but important from an organization point of view.
+
+    The majority of the time teams don’t focus at all on this small details because they bring no value to the API but as mentioned they bring value from the fact that it’s a small detail that can be part of a set of small details that together makes your application more enjoyable and most of all makes you proud of your work. We can consider it in IT “Nice to have…”
+
+Adding ***ApiInfo*** couldn’t have been easier, so I present it by a simple example you can find in the class **SpringFoxConfig.java**
+
+
+
+First we will see how the swagger-ui looks **without** ApiInfo:
+
+```
+[Image of swagger-ui without ApiInfo](SpringBootSwaggerFirefoxAndOpenApiTestings\SpringBoot-SwaggerExamples\SwaggerApiInfoExample\dev_resources)
+```
+
+Now we will see how the swagger-ui looks **with** ApiInfo:
+
+
+
+So we can see that with the **ApiInfo** based on our example added a lot of new things:
+
+<u>Point 1</u>: The **title** is now more personalized for your application, and this believe me it’s important when you manage a dozen of microservices each with their own swagger interface and you want to test them individually.
+
+<u>Point 2</u>: We have a **description** section where we can add information that describes the point of this swagger interface or the business logic that this API’s expose.
+
+<u>Point 3</u>: We expose an URL that can redirect the user to a main page of the developing team that manages this bundle of endpoints.
+
+<u>Point 4</u>: We expose a way for someone to **contact us**. And this for me it’s the most important thing in an API world, you should make the effort to make the proper documentation for consumers and if that documentation is not enough then you should leave at least a way for them to contact you for a feedback.
+
+Let’s get deeper in the details: the method ***.description()*** can be very powerful because we can add HTML code. Well actually it’s a bit fake the statement but in reality it’s called: [CommonMark syntax](https://spec.commonmark.org/) (learn it and you can do amazing stuff).