Problems with Likes-Implementation

1. ExerciseId and ProjectIds are still mixed up Although called "ExerciseId", it is called with ProjectId

   Hint: Since ExerciseId's can contain slashes @GetMapping("/numberOfLikes/{ExerciseID}") may not work any more. Follow solution in ExerciseResource

2. How is it checked, that a user cannot like an exercise, he/she does not have access to? Can a user query likes from any other user?

   • @GetMapping("/hasLiked/{ExerciseID}")
   • @DeleteMapping("/unlikeExercise/{ExerciseID}")
   • @GetMapping("/hasLiked/{ExerciseID}")

3. LikesRepository: Performance quite often likes are queried by exerciseId (and UserId), however now database indices are defined on these columns.

4. Api-Restructuring

   Naming does not really follow code conventions:

   old	better
   POST api/likes	POST api/likes
   PUT api/likes	PUT api/likes
   PUT api/likes	PUT api/likes
   PUT api/likeExercise	PUT api/likes what is the difference to PUT api/likes ?
   DELETE api/unlikeMapping	DELETE api/user/likes/{exerciseId} see above on exerciseId with slashes
   GET api/likes	GET api/likes/{exerciseId} see above on exerciseId with slashes
   GET api/numberOfLikes	GET api/likes/{exerciseId} see above on exerciseId with slashes
   GET api/hasLiked	GET api/user/likes/{exerciseId} see above on exerciseId with slashes
   ...	...