Should we send primary key in response to restAPI request in springboot-CodePudding

I am learning SpringBoot and trying to build some rest API using @RestController. I have created below controller

@GetMapping("/v1/search/symptom/{symptom}")
    public List<DoctorDTO> getDoctorsForSymptom(@PathVariable("symptom") String symptomQuery){
        List<DoctorDTO> doctorDTOList = this.symptomService.getDoctorsForSymptom(symptomQuery);
        //we can add code here for caching the result to make response faster
        return doctorDTOList;
    }

which is returning a list of objects of class DoctorDTO which DTO class for original entity class Doctor.

public class Doctor {
    private long doctorId;
    private String name;
    private int age;
    private String mobileNum;
    private MedicalSpeciality medicalSpeciality;
    private List<Slot> slots;
    private List<DoctorSymptomAssociation> doctorSymtomAssociations;
}

I am sending DoctorDTO object but it contains primary key for Doctor class also. I need to send the primary keys for each record so that if the user selects a particular doctor and send a new request with that selected doctor primary key in it, I can perform some operations with the help of that primary key.

But I read that sending primary key for a record with the response is not a good practice.

So, please tell me how can I refer to the same doctor after receiving new request from the user if I don't include doctor's primary key in first response to the user.

Also, please explain is it a good approach to add another column for UUID in the Doctor entity and send that UUID value to the user in first response instead of primary key. But UUID has its own cons. So, if there is any better approach then please mention. I am using MySQL database.

CodePudding user response：

Primary key is a perfectly fine as long as you don't have a unique key in your class and may want to use this.

CodePudding user response：

There is nothing wrong with providing primary keys, or in other words identifiers in responses. Especially after creating some new entity. How else your clients would be able to request doctors from your service?

Regarding introducing an additional UUID field in your entity. Having several identifiers in one entity is not a good practice. Just think about how (and if) will you be able to control the uniqueness of your objects in this case.

Speaking about using UUID vs auto-incremented integer\long values. It depends on your exact situation. In short, using UUIDs reduces a lot of risks in case you will need to accept client-generated identifiers, or if you're building a distributed system. During migration between services, UUIDs will also help to avoid a lot of issues.

If you decide to go with using UUID as your primary key, I would highly recommend using the sixth version, which is time ordered. I can recommend such a UUID generator, which supports the sixth version.