Common to Hardcode for Spring Boot Java Backend Coding?

This is my first day working on backend. My background is frontend Java developer. I have been looking at many tutorials and I have noticed that in all tutorials the String literals are hardcoded and there are no class/method/inline documentation. Is this normal/acceptable for backend coding?

Example tutorials

1. https://www.jackrutorial.com/2018/04/spring-boot-user-registration-login.html

2. https://medium.com/@kamer.dev/spring-boot-user-registration-and-login-43a33ea19745

In a frontend Java based project, I would never hardcode any values. Take this example,

package com.jackrutorial.controller;
import javax.validation.Valid;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.stereotype.Controller;
import org.springframework.validation.BindingResult;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.servlet.ModelAndView;
import com.jackrutorial.model.User;
import com.jackrutorial.service.UserService;
@Controller
public class UserController {
@Autowired
private UserService userService;
@RequestMapping(value= {"/", "/login"}, method=RequestMethod.GET)
public ModelAndView login() {
ModelAndView model = new ModelAndView();
model.setViewName("user/login");
return model;
}
@RequestMapping(value= {"/signup"}, method=RequestMethod.GET)
public ModelAndView signup() {
ModelAndView model = new ModelAndView();
User user = new User();
model.addObject("user", user);
model.setViewName("user/signup");
return model;
}
@RequestMapping(value= {"/signup"}, method=RequestMethod.POST)
public ModelAndView createUser(@Valid User user, BindingResult bindingResult) {
ModelAndView model = new ModelAndView();
User userExists = userService.findUserByEmail(user.getEmail());
if(userExists != null) {
bindingResult.rejectValue("email", "error.user", "This email already exists!");
}
if(bindingResult.hasErrors()) {
model.setViewName("user/signup");
} else {
userService.saveUser(user);
model.addObject("msg", "User has been registered successfully!");
model.addObject("user", new User());
model.setViewName("user/signup");
}
return model;
}
@RequestMapping(value= {"/home/home"}, method=RequestMethod.GET)
public ModelAndView home() {
ModelAndView model = new ModelAndView();
Authentication auth = SecurityContextHolder.getContext().getAuthentication();
User user = userService.findUserByEmail(auth.getName());
model.addObject("userName", user.getFirstname() + " " + user.getLastname());
model.setViewName("home/home");
return model;
}
@RequestMapping(value= {"/access_denied"}, method=RequestMethod.GET)
public ModelAndView accessDenied() {
ModelAndView model = new ModelAndView();
model.setViewName("errors/access_denied");
return model;
}
}

String values such as "user/signup" or "errors/access_denied", ect is (can be) used multiple times. It would be better to create constants to avoid any spelling mistakes and have one point of reference, ect. Ultimately, I am just trying to understand what is the best practice for backend development. If this was frontend code, my Lead would be tearing me a new one.

It's all basically just maintainability question. After all, the optimizations during compilation most probably can handle these literals so that they are only created once thus not affecting performance or memory usage.

For me it has always been no-brainer to use constants for strings that do not change and especially if they are used multiple times in the code.

And if I were your lead and saw this, I would probably tear you a new one too

As @drodil pointed out its about maintainability, I personally do not make constants since it's easier to see the endpoint right then and there. You can add Controller level @RequestMapping and move the common part of the endpoint there.

Apart from that, you can have Controller tests so that you won't have misspelling issue.

Both of the approaches would work just fine.