spring-web-services is a course repo for building SOAP and REST APIs with Spring

A course repository, not a library

spring-web-services is the repository for a course titled Master Java Web Services and REST API with Spring Boot, and the description says plainly that it is about learning how to create SOAP and RESTful web services with Spring and Spring Boot. That framing decides how to evaluate it. There is no published library, no versioned artifact and no release history, and the repository is MIT licensed with the code and the supporting notes committed together. The top level listing shows the shape of a course repository rather than an application. There are step directories for jpa-in-10-steps, spring-in-10-steps, springboot-in-10-steps and restful-web-services-v2, a soap-web-services directory, a presentation PDF, and a set of Markdown files that read like instructor notes, including Todo.md, course-updates.md, webserviceconfig-changes.md, 2.5.0-upgrade-faq.md and 3.0.0-upgrade-notes.md. The last two are the interesting ones for an engineer, because they document what changed when the Spring and Boot versions moved, which is exactly the kind of thing you discover the hard way when you copy example code into a project on a newer baseline.

The REST half, taught through a social media API

The first part of the course covers RESTful web services, and the framing is that architectures are moving towards microservices and RESTful web services are the first step to developing great microservices. The example application is a social media application, and the resources are built with a set of features the documentation lists explicitly: versioning, exception handling, documentation with Swagger, basic authentication with Spring Security, filtering and HATEOAS. The stated outcome is that you will be able to develop and design RESTful web services, understand the best practices in designing them, connect them to a backend with JPA, implement exception handling, validation, HATEOAS and filtering, version your services, monitor them with Spring Boot Actuator and document them with Swagger. The toolchain listed for this half is Spring for dependency management, Spring MVC or Spring REST, Spring Boot, Spring Security, Spring Boot Actuator, Swagger, Maven, Eclipse, Postman as a REST services client, and the Tomcat embedded web server. The combination of Actuator and Swagger in the same list is the part that matters for a working service, since one is how you know it is alive and the other is how anyone else can call it.

The SOAP half, and why it is still worth teaching

The second part covers SOAP web services for a course management application, and the documentation is candid about the state of the market, saying that while the use of SOAP web services is on the way down, there are still a considerable number of web services using this approach. That framing is the honest reason to look at the SOAP examples in 2026, because most of the services still in that position are ones somebody has to maintain, and SOAP is unforgiving in ways REST is not. The approach taught is contract first, defining an XSD for requests and responses before any implementation code exists, which is the part that catches people out. The documentation covers WSDL and its SOAP Header, SOAP Body and SOAP Fault, XSD and JAXB, and you implement three SOAP web services with exception handling and basic security using WS Security. The toolchain for this half swaps in Spring Web Services and Wizdler, a SOAP services browser plugin, and keeps Spring, Spring Boot, Spring Security, Swagger, Maven, Eclipse and the embedded Tomcat.

Starting MySQL, because the examples need a real database

The examples talk to a MySQL instance, and the documentation gives the exact container to run for it.

docker run --detach --env MYSQL_ROOT_PASSWORD=dummypassword --env MYSQL_USER=social-media-user --env MYSQL_PASSWORD=dummypassword --env MYSQL_DATABASE=social-media-database --name mysql --publish 3306:3306 mysql:8-oracle

The command starts a detached container named mysql, publishes port 3306 on the host, and creates a database called social-media-database with a user called social-media-user. The image tag is mysql:8-oracle, so it is the Oracle build of MySQL 8. The database name is not arbitrary, it is the schema the JPA examples map to, and the credentials are the ones the example configuration files expect, which is why the environment variables are spelled out rather than left to defaults. If your examples fail to start, a mismatched database name or user is the first thing to check, because a JPA application with a wrong datasource configuration usually fails at startup with a connection error that looks like a code problem.

Running the examples, which assumes Eclipse and Maven

The documented workflow for running the examples is Eclipse-centric, and the steps are listed in full. You download the zip or clone the Git repository, unzip it if you downloaded one, open Command Prompt and change directory to the folder containing pom.xml, and then in Eclipse you use File, Import, Existing Maven Project, move to the folder where you unzipped the zip and select the right project. You then choose the Spring Boot Application file by searching for @SpringBootApplication, right click it and run as Java application, and the documentation says you are all set. There is no mention of a command line build in the running section, which is worth flagging, because the Maven build is obviously there since the project is a pom.xml project and the install section covers Maven. The documentation also separates tool installation from running, offering an installation video playlist, a git repository for getting started in five steps and a PDF guide, and the expectations section is unusually clear about the baseline. You should know Java, a basic understanding of web application development is a bonus but not mandatory, the same goes for a basic understanding of Spring and Spring Boot since there are separate sections introducing them, and you are not expected to have any experience with Eclipse, Maven or Tomcat.

What the repository is for, and what it is not

The intended use is stated in the Step Wise Details section, which simply says to refer to each step, and the course structure is signposted by the table of contents with separate sections for installing tools, running examples, the course overview and the about section. In practice, this repository is a worked answer key. Every feature the lessons discuss exists in the code, which means you can read how versioning, exception handling, Swagger documentation, Spring Security, filtering and HATEOAS look when they are assembled into a running application rather than described in isolation. That is a real advantage over a blog series, and it is the reason to clone it. What it is not is a framework. The structure follows the curriculum, with a directory per course module, and the code carries the assumptions of a teaching pace, which means a simplified error handler, a hardcoded set of entities and the particular test data the lessons use. Copying a module wholesale into a production project means inheriting those choices. The same goes for the SOAP half, where the contract first approach is the genuinely transferable idea and the three example services are illustrative rather than general.

Where this repository is the wrong choice

The boundaries are clear. The first is that it is not maintained as a library. There are no GitHub releases, the version information lives in the pom files, and the presence of upgrade notes for 2.5.0 and 3.0.0 tells you the examples were written against a particular Spring and Boot generation and patched forward when the maintainer had time. The second is the tooling dependency. The documented path assumes Eclipse, Maven and an embedded Tomcat, which is fine for learning and awkward for CI, and the Makefile or Gradle route to build the same project is not described. The third is scope. This is two courses in one repository, and if your problem is only REST you will step past a lot of SOAP code, and if your problem is only SOAP the same applies in reverse. The fourth is the database. The examples need a specific MySQL schema and user, and while the container command makes that easy, it is a hard dependency on a running database for what is otherwise a self-contained example set. And the fifth is the one that catches most people, which is that the code is a snapshot of a course, so the newer Spring conventions, such as the virtual threads and the jakarta namespace migration, may not be reflected in it. Read it as a well-made example of how it was done in that era, and check the version notes before copying anything.

Editorial conclusion

Adopt this repository as a reference implementation if you are learning REST or SOAP services with Spring Boot and want working code for a social media API and a course management API to read alongside the lessons. Do not adopt it as a production starting point, because it is teaching code that is explicitly shaped around a curriculum, and the pinned dependency versions, the Eclipse-oriented workflow and the lack of any release process all point away from that use. Verify two things before you build on it: the Spring and Boot versions the examples were written against, since the repository carries upgrade notes for 2.5.0 and 3.0.0 that indicate version churn, and the MySQL connection, since the examples expect a specific database and user set up by the container command. The practical first step is to start the database with the documented docker run command, then import the restful-web-services-v2 project into your IDE and run the @SpringBootApplication class.

Frequently asked questions

Official sources

1. in28minutes/spring-web-services on GitHub
2. Issues
3. License: MIT
4. README