How to organize access to resources in REST API?

Question

API

I am developing a media service REST API. Media is audio (music bands, albums, tracks...) and video (movies, series, seasons, episodes...). All media in the database are stored in one table - Media. In the API for each media type, I decided to use several endpoints:

/movies/
/music-groups/{id}/albums/{id}/tracks/{id}
и т.д.

This option seemed convenient to me, because. each type of media may contain some specific fields + search filters for each type may be different.
Users should be able to add media to their favorites list and then view that list.
The list of liked media will be in another database (the application is divided into small modules, each of which is responsible for some feature + each module can only use its own database).
Question : how to return information about liked media if the module does not know about the type of media, but only knows the identifier?
Is it normal to have an endpoint /media/{id} that will determine the type of media and redirect the user to the desired path (for example, the user liked the music track, he goes to the link /media/{track_id}, and he is redirected to /music-groups/ {mg_id}/albums/{a_id}/tracks/{track_id})?

Answer 1

Too smart. Everything should be very simple. What is a media type? Music or video? So by

/movies/genre/{id}/film/{id} - movies
/music/albums/{id}/tracks/{id} - music

Further. If I know the id of a track or movie, I should be able to access it directly:
If I don't know what track I need, I ask for all tracks from the musical direction, for example, rap has id = 13
At this request, bundles of directions are issued for 100, 300 or 1000 pieces, depending on the resources, and you can specify a paginator
That is why it is better to pass the parameters explicitly in the url like style=13&page=2 because you won’t get confused what 13 is and what 2 is
. to get cities for example. View request:
gives 100 pairs of the form "genre name -> id" so by making 5 queries with page=0/1/2/3/4 I can have the entire database of possible genres in my application. You can make a method to get the genre of a particular song:
Etc.

music/getalbums/1456 - get all albums of an artist
music/detailalbum/1456 - get all data about an album (year of release, etc.)
music/tracksalbum/1456 - get a list of tracks of a particular album
In general, do not go from the particular to the general, but vice versa, imagine where to start work for a person who knows nothing. Enter the maximum atomicity of queries so that they are not related to each other in any way. And a person will first receive jarni, by genre a list of performers, by him a list of albums, by him a list of songs, by him data about the desired song. And these are all separate requests.

Answer 2

Somehow it is not clear: usually methods (analogues: create, set, get, update, delete, etc.) are taken out (mounted) on the entry points of client requests (endpoint).
All parameters passed to the method are already POST JSON (in most cases).
There are also exceptions when the methods are simple and the parameters go in the endpoint address, but then the address should return WITHOUT redirects and the server should correctly "understand" this request, because in fact, this is already a search query that is not related to RESTful.

e.g. the user liked the music track, he follows the link /media/{track_id}, and he is redirected to /music-groups/{mg_id}/albums/{a_id}/tracks/{track_id}

We do not change the address (without a redirect!), but we can return extended information about the track, group, album in the form of a structure (an array or a tree) in the response.