Add additional endpoints

InputUsername commented 5 months ago

This PR implements some of the API endpoints from #4:

Core:
- /1/user/(user_name)/similar-users - Client::user_similar_users;
- /1/user/(user_name)/similar-to/(other_user_name) - Client::user_similar_to.
- Playlists:
- /1/user/(playlist_user_name)/playlists - Client::user_playlists;
- /1/user/(playlist_user_name)/playlists/createdfor - Client::user_playlists_created_for;
- /1/user/(playlist_user_name)/playlists/collaborator - Client::user_playlists_collaborator;
- /1/playlist/(playlist_mbid) - Client::get_playlist.
- /1/playlist/create - Client::playlist_create;
- /1/playlist/(playlist_mbid)/delete - Client::playlist_delete;
- /1/playlist/(playlist_mbid)/copy - Client::playlist_copy.
- Statistics:
- /1/stats/release-group/(release_group_mbid)/listeners - Client::release_group_listeners.
- Social:
- /1/user/(user_name)/followers - Client::user_followers;
- /1/user/(user_name)/following - Client::user_following;
- /1/user/(user_name)/follow - Client::user_follow;
- /1/user/(user_name)/unfollow - Client::user_unfollow.

InputUsername commented 4 months ago

@shymega in case you missed it, could you take a look at this?

RustyNova016 commented 4 months ago

The JSPF format doesn't correspond to the official. And according to the playlist creation endpoint it seems a lot of fields are optional when in the code they aren't.

It seems to be fine for playlist fetching tho.

shymega commented 4 months ago

Hey, sorry - you're right, I did miss this. The only thing I'd say is that it's a fairly large PR, and I wonder if we can split it into 'groups' based on endpoints. For example, one PR for '/user/*' endpoints, and so on. It's quite a lot to review without making mistakes.

shymega commented 4 months ago

We also need to rebase against main. There's a merge conflict on my end...

RustyNova016 commented 4 months ago

Hey, sorry - you're right, I did miss this. The only thing I'd say is that it's a fairly large PR, and I wonder if we can split it into 'groups' based on endpoints. For example, one PR for '/user/*' endpoints, and so on. It's quite a lot to review without making mistakes.

At this point that would be better to just ditch the branch and go directly into the #25 refactor.

BTW, I didn't encounter any merge conflict while making my own 8.0 branch. Odd

shymega commented 4 months ago

Hey, sorry - you're right, I did miss this. The only thing I'd say is that it's a fairly large PR, and I wonder if we can split it into 'groups' based on endpoints. For example, one PR for '/user/*' endpoints, and so on. It's quite a lot to review without making mistakes.

At this point that would be better to just ditch the branch and go directly into the #25 refactor.

BTW, I didn't encounter any merge conflict while making my own 8.0 branch. Odd

It would be better to split PRs. Easier to track. Having so many changes in one PR, will just make life difficult.

I had a merge conflict when rebasing against main.

InputUsername commented 4 months ago

Hi, sorry for the slow response, prioritizing my master's thesis right now :smile:

I agree that splitting up is probably a good idea.

At this point that would be better to just ditch the branch and go directly into the https://github.com/InputUsername/listenbrainz-rs/issues/25 refactor.

Not sure, this branch contains a bunch of additional endpoints that we definitely want to keep. But doing the refactor first and then porting over the new endpoints in parts sounds like a good idea.

@shymega I currently don't have a lot of time for this, could you take charge?

shymega commented 4 months ago

Hi, sorry for the slow response, prioritizing my master's thesis right now 😄

I agree that splitting up is probably a good idea.

At this point that would be better to just ditch the branch and go directly into the #25 refactor.

Not sure, this branch contains a bunch of additional endpoints that we definitely want to keep. But doing the refactor first and then porting over the new endpoints in parts sounds like a good idea.

@shymega I currently don't have a lot of time for this, could you take charge?

I can take a look on weekends. I may be signing a contract for Mon-Wed next week, and then have another part-time thing for the rest of the week.

I need to revert the merge commits used in this PR, and edit the history. Ideally PRs shouldn't have merge commits, and just use the rebase method against main. I will notify the PR here once that's done, and a git pull --rebase is necessary on local checkouts.

shymega commented 4 months ago

This rebase won't be easy.

@InputUsername Can you provide me with a list of SHAs you want in this PR, and I'll then cherry-pick them, rebase the branches you want in this PR, and rebase against main too.

It's needed because I need to remove the merge commits, but I don't want to miss any of your work. Feel free to email me or state here.

Cheers.

InputUsername commented 4 months ago

@shymega

5ceac2e19604540dbb65242c612afd5f713e0c41
5a367cba61138b12b32d99b07d5bb05547407f64
0dd89fedb7e34ae37840710b7e2d063d880ff195
e5ffd166d5d30dad01730d48be7b3cd65f1b867a
1c9387ac0e1bcf2534b1405b6c0d30c291a02444
3fefae0dae6eb5d3afaa1afd96d1c06f148a74ee
26573249d6d6355a927171dd9847fd35ca7f2dc2
5cfaa1159f81aa2c0a3cca49edd95ef254406230
06278f69d64f3b48611f86b5e9d5ae567ef25a09
1cc59ee07074a7221dd24c25dae8720279a583ce
04237234dcb0204fc9941ead83da9891700e32e0
8e64512ded57cfbd544a5ea4fa1c95c9fdd4709d
59b93e06d3a4d0a68d49f1936609c1516814b49c
9715b0e7caff5728673621695036cae1b799d193

shymega commented 4 months ago

In the end, reverting two merge commits would have been messy. As main has merge commits anyway, I just rebased this PR against main. I've pushed it to my fork.

I had to decide which were the new changes, and old changes. Any queries, feel free to let me know what I've missed.

RustyNova016 commented 3 months ago

Since #32 is based on this branch and merge in it, feel free to tell me if there's any change to do on it

shymega commented 3 months ago

So far, you don't need to do anything. I'm waiting for @InputUsername to assess my branch, and check we can force-push to this PR.

I don't want to break anything, but when we do overwrite this PR with my branch, you may need to rebase #32.

InputUsername commented 3 months ago

@shymega I had a look (sorry for the delay!) and it seems like your branch is good apart from the fact that the Endpoint::StatsReleaseGroupListeners variant got removed somehow? Anyway, I think we can go ahead and overwrite this PR, CI should catch any major issues.

Next time I'll make sure not to keep a branch hanging around for over 2 years :sweat_smile:

shymega commented 3 months ago

@shymega I had a look (sorry for the delay!) and it seems like your branch is good apart from the fact that the Endpoint::StatsReleaseGroupListeners variant got removed somehow? Anyway, I think we can go ahead and overwrite this PR, CI should catch any major issues.

Next time I'll make sure not to keep a branch hanging around for over 2 years 😅

How does it look now? It should now be ready to force-push.

I also found a compile error which I've fixed - missing brace.

InputUsername commented 3 months ago

@shymega I had a look (sorry for the delay!) and it seems like your branch is good apart from the fact that the Endpoint::StatsReleaseGroupListeners variant got removed somehow? Anyway, I think we can go ahead and overwrite this PR, CI should catch any major issues. Next time I'll make sure not to keep a branch hanging around for over 2 years 😅

How does it look now? It should now be ready to force-push.

I also found a compile error which I've fixed - missing brace.

Good catch - let's go for it!

shymega commented 3 months ago

Just done it. Let's see how CI goes now.

InputUsername / listenbrainz-rs

Add additional endpoints #29