#Spring Boot standards and development.

1 messages · Page 1 of 1 (latest)

fallow tree
#

We had an assignment that has requirements that you only implement the necessary endpoints. What does this mean in normal settings.

In my implementation (due to the early stage of development of the app), I have made controller -> service -> repo with Jvka validation in DTO entities.

I have a basic implementation of the findAll, findbyid, and delete commands in an abstract generic class that I use to avoid reimplementing repeating code with custom implementations of any other methods.

Have I done it correctly this way? Im quite confused as in what API and what endpoints I should expose.

What are your normal tips on the work with Spring Boot api creations?

craggy kettleBOT
#

<@&987246584574140416> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
We had an assignment that has requirements that you only implement the necessary endpoints. What does this mean in normal settings. In my implementation (due to the early stage of development of the app), I have made controller -> service -> repo with Jv

o limited time or resources), I focused on creating the endpoints that were required for the assignment and did not include any additional endpoints that were not specified. This means that I only implemented the functionalities that were necessary for the application to meet the requirements set out in the assignment.

In a normal setting, this would typically mean following a similar approach of prioritizing and implementing only the endpoints or features that are necessary for the application to function as intended. This can help streamline development efforts, reduce unnecessary complexity, and ensure that the project stays focused on meeting its core objectives.

By only implementing necessary endpoints, developers can also avoid feature creep or scope creep, where additional functionalities are added beyond what was initially planned or required. This can help keep projects on track, within budget, and delivered on time.

Overall, focusing on implementing only necessary endpoints is a best practice in software development to ensure efficient use of resources, maintain project focus, and deliver a product that meets its intended goals.

fallow tree
#

I can provide examples of what I did if it sounds confusing. Arguably, I have difficulty understanding "only necessary endpoints" How would I know what will be necessary and what will not be?

Also, what is fine to leave exposed and what is better to not expose at all?

simple socket
#

I have difficulty understanding "only necessary endpoints" How would I know what will be necessary and what will not be?
Seems like you are missing some information from a previous lecture where you maybe discussed the "necessary" endpoints? Because in itself this assignment doesn't make sense as the necessary endpoints would be none by default

fallow tree
#
public abstract class BaseCrudController<RequestDTO, ResponseDTO, ID> {
    protected final BaseCrudService<RequestDTO, ResponseDTO, ID> baseCrudService;

    protected BaseCrudController(BaseCrudService<RequestDTO, ResponseDTO, ID> baseCrudService) {
        this.baseCrudService = baseCrudService;
    }

    @GetMapping
    public ResponseEntity<List<ResponseDTO>> findAll() {
        return ResponseEntity.ok(baseCrudService.findAll());
    }

    @GetMapping("/{id}")
    public ResponseEntity<ResponseDTO> findById(@PathVariable ID id) {
        return baseCrudService.findById(id).map(ResponseEntity::ok).orElse(ResponseEntity.notFound().build());
    }

    @PostMapping
    public ResponseEntity<ResponseDTO> create(@Validated @RequestBody RequestDTO requestDto) {

        var createdRequestDTO = baseCrudService.save(requestDto);
        return ResponseEntity.status(HttpStatus.CREATED).body(createdRequestDTO);

    }

    @PutMapping("/{id}")
    public ResponseEntity<ResponseDTO> update(@PathVariable ID id, @Validated @RequestBody RequestDTO requestDto) {

        var updatedRequestDTO = baseCrudService.update(requestDto, id);
        return ResponseEntity.ok(updatedRequestDTO);

    }

    @PatchMapping("/{id}")
    public ResponseEntity<ResponseDTO> patch(@PathVariable ID id, @RequestBody Map<String, Object> updates) {
        var updatedRequestDto = baseCrudService.patch(updates, id);
        return ResponseEntity.ok(updatedRequestDto);
    }

    @DeleteMapping("/{id}")
    public ResponseEntity<Void> delete(@PathVariable ID id) {
        baseCrudService.deleteById(id);
        return ResponseEntity.noContent().build();
    }
}```
#

this how my base controller class looks currently

#
@RestController
@RequestMapping("/api-rest/v1/AnyEntitiy")
public class AnyEntitiyController extends BaseCrudController<AnyEntitiyRequestDto, AnyEntitiyResponseDto,String> {
    @Autowired
    public AnyEntitiyController(AnyEntitiyService service) {
        super(service);
    }
}```
simple socket
#

Maybe the necessary endpoints of a CRUD application?

fallow tree
#

So far I am unsure what I will need due to really early stage of entire thing

#

This is how my service layer looks

#

it has similar strucutre

simple socket
#

What does the BaseCrudService look like?

fallow tree
#

Its the long one

#

above the AnyEntitity

#

Oh

#

Nvm

#

I was posting it, its too long

#
public interface BaseCrudService<RequestDTO,ResponseDTO,ID> {
    List<ResponseDTO> findAll();
    Optional<ResponseDTO> findById(ID id);
    ResponseDTO save(RequestDTO Dto);
    ResponseDTO update(RequestDTO Dto, ID idPath);
    ResponseDTO patch(Map<String, Object> updates, ID idPath);
    boolean existsById(ID id);
    void deleteById(ID id);
}```

This is interface I use to be able to use common share functions in general class
#

The patch/put/save methods currently will throw exceptions is because I want them to have custom validation I will get to know at some point in future

simple socket
#

As the last thing, can you also show the repository?

fallow tree
#

@Repository
public interface AnyEntityRepository extends CrudRepository<AnyEntityEntity,String> {

}

#

import org.springframework.data.repository.CrudRepository;
import org.springframework.stereotype.Repository;

Im using normal springframework integration

#

unless I need custom methods

simple socket
#

That seems alright

fallow tree
#

I can give example of validation DTO I am using.

#
public record AirlineRequestDto(
        @NotBlank(message = "Airline: ID is required", groups = OnCreate.class)
        @Null(message = "Airline: ID UPDATE/PATCH is forbidden, primary key violation", groups = {OnUpdate.class, OnPatch.class})
        @Size(max = 3, message = "Airline: ID cannot exceed 3 characters", groups = OnCreate.class)
        String airlineId, // Primary key

        @NotBlank(message = "Airline: name is required", groups = {OnCreate.class, OnUpdate.class})
        @Size(max = 50, message = "Airline: name cannot exceed 50 characters", groups = {OnCreate.class, OnUpdate.class, OnPatch.class})
        String name,

        @NotBlank(message = "Airline: shortcode is required", groups = {OnCreate.class, OnUpdate.class})
        @Size(max = 3, message = "Airline: shortcode cannot exceed 3 characters", groups = {OnCreate.class, OnUpdate.class, OnPatch.class})
        String shortcode
) implements Serializable, IdentifiableDto<String>```

Im using a simple interface that I have yet to implement that should change so validation works on correct functions
simple socket
#

Have I done it correctly this way? Im quite confused as in what API and what endpoints I should expose.
As this seems to be a CRUD application you need create, read, update, delete methods

fallow tree
#

read?

#

delete is implemented I think because its by ID

simple socket
#

If only the necessary endpoints are asked for, one could argue that existsById is not necessary because you also get that information from findById

simple socket
fallow tree
#

I have findAll, findById?

#

Entities are only on service layer, at least its supposedly the correct aproach

simple socket
fallow tree
#

I pass RequestDto from controller into service, that service uses it, then gets entity and maps it to a responseDTo, which is returned to controller

#

So i have practically full control of returned information and dont double validate information

#

Does this structure look correct to you? (I cut a lot from the image, but the structure is the same) (working on web part so far)

simple socket
#

It always depends on the application, The CrudService is generic and might fit for every entity you have. But if the entities are handled differently in the future it doesn't make sense and usually you have a service for each entity

fallow tree
#

Yes, I use service class for each entitie

#

Generic class is used purely for code that I dont really see changing much

simple socket
#

whats the difference between api and web folder in the controller?

fallow tree
#

api are the controllers

#

web is for thymeleaf

#

Im working on that part currently (aint much there yet)

simple socket
#

what exactly does this mean? so there are just more controllers in there which return thymeleaf pages?

fallow tree
#

So far nothing, I just started on that

#

our task is partial, first was Rest API

#

now thymeleaf, but I will deal with it myself

simple socket
#

and what is the thymeleaf task supposed to do?

fallow tree
#

Seems to be validations/restrictions/error messages handleing

simple socket
#

Doesn't really make sense to me. Thymeleaf is a template engine

fallow tree
#

Lets just say you aren't the only one confused here

#

wait WebApp

#

I cannot read it seems

simple socket
#

So usually you use thymeleaf to return some HTML pages with content you get from somewhere or do other stuff wchich required a somewhat dynamic content

#

But the rest seems to be okay for now. s you get more information over the time it will change for sure

fallow tree
#

Yeah, but grading happens before we get that information. 🙂

#

at least I guess I did it fine

#

have to go currently, thanks for help. Was worried I screwed up really bad.

#

if you have any suggestions will be happy to read them later

#

Thymeleaf web application