Spring REST api - идентификатор внешнего ключа вместо всего объекта - PullRequest
Новая
       104

Spring REST api - идентификатор внешнего ключа вместо всего объекта

0 голосов
/ 18 июня 2020

У меня проблема с Json, возвращаемым моим методом REST api GET.

Вот как выглядят мои объекты: 

@Entity
public class Employee {
    ...
    @ManyToOne(fetch = FetchType.EAGER, optional = false)
    @JoinColumn(name = "department_id", nullable = true)
    private Department department;
}

@Entity
public class Department {
    ...
    @OneToMany(mappedBy = "department", fetch = FetchType.EAGER, cascade = CascadeType.ALL)
    @JsonBackReference
    private Set<Employee> employees;
}

И это ответ, который я получаю, пока Я пытаюсь ПОЛУЧИТЬ Сотрудника по его идентификатору: 

{
    "id": 1,
    "surname": "smith",
    "department": {
      "id": 1,
      "name": "HR",
      "room": "13"
    }
}

Теперь вместо всего объекта «Отдел» я хотел бы получить простой идентификатор: "department_id": 1, , и я не Я не знаю, как это сделать.

Второй вопрос: что за good practise в этой ситуации в REST api? Следует ли мне оставить все как есть; выставить только id (то, что я прошу вас, как делать); или использовать DTO и вообще его не показывать? Более того , в любом случае я собираюсь добавить _links в этот пользовательский отдел, и в этом случае я подумал, что оставить только идентификатор должно быть нормально (скажите мне, если я ошибаюсь). Ждем ваших ответов!

Ответы [ 2 ]

2 голосов
/ 18 июня 2020

Хорошей практикой является определение DTO, представляющего данные, предоставляемые вашим API. Это должно быть отделено от вашего домена (Employee), так как это даст вам большую гибкость, как и то, чего вы хотите достичь. 

class EmployeeDTO extends RepresentationModel {
    private long id;
    private String surname;
    private long departmentId;

   // getters and setters
}

Это должно сработать. Конечно, вам нужно сопоставить сущность Employee с EmployeeDTO. ПредставлениеModel содержит свойство _links, которое вы хотите для HATEOAS (например, посмотрите https://www.baeldung.com/spring-hateoas-tutorial)

О раскрытии идентификатора из вашей базы данных, я думаю, что это хорошая причина для невыполнение этого требования означает, что вы бесплатно предоставляете информацию о размере своей базы данных, а это то, чего вы, возможно, не захотите. Из этого можно даже получить дополнительную информацию.

Здесь вы можете найти хорошее обсуждение topi c: Раскрытие идентификаторов баз данных - угроза безопасности?

Я бы хотел Предлагаем взглянуть на UUID, который является универсально уникальным буквенно-цифровым c идентификатором, который не раскрывает эту информацию о ваших данных. Подробнее о UUID: https://www.baeldung.com/java-uuid

1 голос
/ 18 июня 2020

@JsonIgnoreProperties

Чтобы просто получить идентификатор отдела без изменения какой-либо реализации, вы можете использовать @JsonIgnoreProperties({"name", "room"}) как следующее 

@ManyToOne(fetch = FetchType.EAGER, optional = false)
@JoinColumn(name = "department_id", nullable = true)
@JsonIgnoreProperties({"name", "room"})
private Department department;

, которое ответит следующим образом 

[
    {
        "id": 1,
        "surname": "smith",
        "department": {
            "id": 1
        }
    }
]

Вы также можете изучить другие способы достижения того же здесь

Передовой опыт

Мы никогда не должны открывать и возвращать наши модальные окна и сущности в ответ на API. Мы можем создавать DTO / DAO для получения и передачи объектов и данных. Вы также можете преобразовать объект в DTO и DTO в объект , используя mappers .

В случае DTO вы можете просто включить идентификатор отдела и можете получить объект, если требуется, используя репозиторий.

...