Hiya
I'm curious if you could update your API to follow standard API practices to make working with it more inline with how devs would expect.
Currently your API returns a 200, even if the request is invalid. This creates implementation issues with external tools.
While working on my mod manager, I want to obtain the URL to the mod site based on the modid of a particular mod. There is no guarantee that the provided modid even has a url end point. So what I would expect to do is to make a HEAD request to validate if the URL exists, since its lightweight and I don't need a full json blob. That's not possible as the api will always return a 200 status code.
Forcing a full GET request each time also creates more burden for the API servers as they always have to do a full request. From a user standpoint, it also adds increased latency when you have to make a full GET for something you could do with the lightweight HEAD.
The API is already published, so I imagine this won't be changed for v1. I just hope that with v2, the status codes move away from request body and is handled at the protocol level.
Hiya
I'm curious if you could update your API to follow standard API practices to make working with it more inline with how devs would expect.
Currently your API returns a 200, even if the request is invalid. This creates implementation issues with external tools.
While working on my mod manager, I want to obtain the URL to the mod site based on the modid of a particular mod. There is no guarantee that the provided modid even has a url end point. So what I would expect to do is to make a HEAD request to validate if the URL exists, since its lightweight and I don't need a full json blob. That's not possible as the api will always return a 200 status code.
Forcing a full GET request each time also creates more burden for the API servers as they always have to do a full request. From a user standpoint, it also adds increased latency when you have to make a full GET for something you could do with the lightweight HEAD.
The API is already published, so I imagine this won't be changed for v1. I just hope that with v2, the status codes move away from request body and is handled at the protocol level.