Server v2 #167
Server v2 #167
Conversation
This reverts commit 7e54577.
Solved Merge conflicts with cuttingedge branch
/v2/Jobs /v2/Jobs/Running /v2/Jobs/Waiting /v2/Jobs/Monitoring
/v2/Jobs /v2/Jobs/Running /v2/Jobs/Waiting /v2/Jobs/Monitoring
…uest so we don't forget to send a response.
|
Yeah this makes sense, let's make a branch of the current working code, like a V01.XX.XX and generate a docker image for that so people can force their server to run that code. |
|
And you can just merge my current json API branch into this Server V2 branch if you want a head start. Once that's done we can close my branch and Implement json API as part of V2 and not have any in V1 |
|
You want a hard cut-over? The way I wrote the current requests, we could still have both parts running, and be future-proof (v3,4,5...) too. |
|
I think something as big as an API changing structure would be enough to do a hard cut-over, it's your call in the end but I think V2 being the version with the big API change makes sense to me and then we just leave the old version alone, maybe patch it every now and then if we need to but otherwise leave it alone. |
|
Also do you want to take the lead on the server side of V2 then? That'll let me focus on doing the frontend V2 implementing all these manga pop-up and search/add pop-up changes that everybody's been wanting. I can also then implement any other changes as a result of the server V2. What do you think? |
|
Sounds like plan! |
Set Komga to also require username and password
- Compression - B/W threshold
# Conflicts: # Tranga/Jobs/JobBoss.cs
# Conflicts: # Tranga/Jobs/JobBoss.cs
# Conflicts: # Tranga/Tranga.csproj
# Conflicts: # Tranga/Jobs/DownloadNewChapters.cs # Tranga/Jobs/JobBoss.cs # Tranga/Jobs/UpdateMetadata.cs
@db-2001
While going over your PR (related issue) I thought about some off the issues we have with the API.
#113 (comment)
Resolves #74
Resolves #114
Could be their own Requests.
By returning a list of JobIds and crosschecking locally which jobs exist, this should be a lot easier on data.
Generally the API transmits a lot more data than it needs to, so streamlining requests (stripping data, splitting single requests into multiple smaller ones) we can react a lot better to changes.
So extending your effort, I propose that we also get going on a Version 2 of the API.
The old API would still be accessible (for now), but we could gradually shift requests to the new one.
I have started writing out the API-Documentation.
If you have any more requests you would like to see, then write them in this PR.