Closed sachin-sankar closed 3 years ago
I strongly disagree with the removal of ID. ID is a very useful thing. Every joke has an unique ID which if could be added, can be used to get a certain joke. I do agree with the customisation of the joke endpoint but don't remove ID.
...even though you suggest the addition of custom flags which of course would be great, I don't think so the flags should be removed from response. Also, instead of headers custom jokes attributes can be passed as JSON (or dictionary) in paramaters.
...even though you suggest the addition of custom flags which of course would be great, I don't think so the flags should be removed from response. Also, instead of headers custom jokes attributes can be passed as JSON (or dictionary) in paramaters.
It is indeed sent as that. @nerdguyahmad
I strongly disagree with the removal of ID. ID is a very useful thing. Every joke has an unique ID which if could be added, can be used to get a certain joke. I do agree with the customization of the joke endpoint but don't remove ID.
Currently you can't get a joke by id and if it was then it would be consuming more resources @nerdguyahmad
...even though you suggest the addition of custom flags which of course would be great, I don't think so the flags should be removed from response. Also, instead of headers custom jokes attributes can be passed as JSON (or dictionary) in paramaters.
There is no use for flags. So it is redundant @nerdguyahmad
I strongly disagree with the removal of ID. ID is a very useful thing. Every joke has an unique ID which if could be added, can be used to get a certain joke. I do agree with the customization of the joke endpoint but don't remove ID.
Currently you can't get a joke by id and if it was then it would be consuming more resources @nerdguyahmad
Personal preference: I don't think so, It is very useful to get a certain joke (I know you cannot get certain joke at the moment but this can be added) and this'd be very useful.
...even though you suggest the addition of custom flags which of course would be great, I don't think so the flags should be removed from response. Also, instead of headers custom jokes attributes can be passed as JSON (or dictionary) in paramaters.
There is no use for flags. So it is redundant @nerdguyahmad
Though customisation can be added, The ability to get the completely random joke shouldn't be removed. So, flags can be helpful in that case.
...even though you suggest the addition of custom flags which of course would be great, I don't think so the flags should be removed from response. Also, instead of headers custom jokes attributes can be passed as JSON (or dictionary) in paramaters.
There is no use for flags. So it is redundant @nerdguyahmad
Though customisation can be added, The ability to get the completely random joke shouldn't be removed. So, flags can be helpful in that case.
What is the use of them? @nerdguyahmad
...even though you suggest the addition of custom flags which of course would be great, I don't think so the flags should be removed from response. Also, instead of headers custom jokes attributes can be passed as JSON (or dictionary) in paramaters.
There is no use for flags. So it is redundant @nerdguyahmad
Though customisation can be added, The ability to get the completely random joke shouldn't be removed. So, flags can be helpful in that case.
What is the use of them? @nerdguyahmad
To of course tell the user that what type of joke they got (in random joke).
Hey @nerdguyahmad and @Creepy-Creeper3625
Kindly see https://github.com/pgamerxdev/projects/issues/23
@nerdguyahmad if #23 comes to action then flags might be irrelevant as the user will set what he needs using flags filter
Hey @nerdguyahmad and @Creepy-Creeper3625 Kindly see #23
Great also add our suggestions about responses. @pgamerxdev
Hey @nerdguyahmad and @Creepy-Creeper3625 Kindly see #23
Great also add our suggestions about responses. @pgamerxdev
Which suggestion?
Hey @nerdguyahmad and @Creepy-Creeper3625 Kindly see #23
Great also add our suggestions about responses. @pgamerxdev
Which suggestion?
about the ai responce and joke responce
Hey @nerdguyahmad and @Creepy-Creeper3625 Kindly see #23
Great also add our suggestions about responses. @pgamerxdev
Which suggestion?
about the ai responce and joke responce
I don't see any suggestions for AI response tho
@pgamerxdev It is under Ai Response
@pgamerxdev It is under Ai Response
Check version 4
@pgamerxdev I don’t see anything related to api response there in #23
@pgamerxdev I don’t see anything related to api response there in #23
What was your suggestion? I removed the api key from the response
Good then
RSA is a great API but it can be better. Here are a few in depth suggestions from a fellow user to improve it a lot. These mainly focus on the response of endpoints.
Jokes Endpoint
The jokes endpoint is a literal joke. Here are a few changes.
Suggestion:
The current endpoint
v3/joke/:type
does not allow the user to define what type of joke they need(Two part,single) Therefore user should be able to define to the endpoint as a header value. Here is a exampleGetting a non nsfw single joke
safe: False
should be considered as nsfw.Jokes Response
The current endpoint returns a dictionary of data as shown below in two types of jokes.
Two part type
Single
The thing about the response is that it contains data that are not necessary. The current response that you saw above is around 310 bytes for the single type. The solution is to remove them from the response.
Data to remove and why:
'error': False
can be removed as we can check if the request succeed by looking into the status code of the response.'type': 'single'
can be removed as the user has no use to it because that he has already requested that type using the header.'id': 74
is a redundant data as the client has nothing to do with it. After removing the above data the response payloads size comes down to 261 bytes. *all the size calculations were done for the single type joke example seen above.The
flags
provide information about the joke but it has nothing to do with the client as the user has already specified his needs and dose not needs to verify them assuming the API returns the correct type. Even if needed the tagnsfw
can be retained andsafe
tag removed as both mean the same thus allowing the user to use the data to verify or else display the data in front end.Response after all removals and improvments:
This brings the size of the response down to 142 bytes. This greatly improves the api's response time and its CPU and ram usage.
AI response
The current endpoint returns the following response,
success
as we can know if it is a error using the error message or the status code.api_key
can be removed because their is no use for it.message
content can be returned as a string rather than a key pair type just like the image endpoint.Response after change:
The AI response endpoint is the most used one these changes allow it to use less CPU and ram preventing outages and quota issues.