You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #106@Bluenix2 suggested the below. I really like this proposed change, so I think we should do it after 106 is merged.
I am not sure how thoroughly this has been discussed, and how much of a say I have in this. But I have some opinions on the new endpoints, you currently have:
GET /size: Get the size of the canvas
GET /pixels: Get the whole canvas
GET /pixel: Get a specific pixel
PUT /pixel: Set a specific pixel
One quick thing I want to mention about /pixels, it doesn't really make sense, we're already at pixels.pythondiscord.com. Making the URL pixels.pythondiscord.com/pixels..
In my opinion, the following seem more RESTful:
GET /canvas/size: Get the size of the canvas alternatively this info could be included in the headers and would be mainly requested using HEAD /canvas.
GET /canvas: Get the whole canvas
alternatively the following two endpoints could use /canvas/pixels
GET /canvas?x=x&y=y: Get a specific pixel
PUT /canvas: Set a specific pixel you could also use query parameters here and the body would only consist of the color
if we wanted to do multiple canvases at any point, might it make more sense to be /canvas/{canvas}/endpoint, similar to how Discord does it (i.e. /channels/1234/messages/5678)
Activity
vcokltfre commentedon Jun 19, 2021
if we wanted to do multiple canvases at any point, might it make more sense to be
/canvas/{canvas}/endpoint, similar to how Discord does it (i.e. /channels/1234/messages/5678)ChrisLovering commentedon Jun 19, 2021
We could do that fairly trivially with fastapi's path routing