I hope images are not too frowned upon, but I thought it’d be simplest if I showed the flow of data and the expected output through arrows. If anyone is extra curious, here is the file.
The server seemingly picks the wrong handler to fulfill the client call. Is this a bug, or is there something I have typed incorrectly / not sufficiently?
No insight, I just want to say I love this clear diagram and it makes sense to take advantage of this forum’s graphical powers!
Well, I’ll just say that the obvious-seeming flow described by these arrows could easily be misleading, because of laziness. Eg perhaps the other code path was “executed” earlier in time, and only now it is forced to produce its output, and is popping up in the output stream at a time when you’re focussed on what the later code is doing.
I absolutely see your point, but the event is as simple as shown (no hidden/other calls!).
I will add however, that by commenting out the “incorrect” endpoint, the server managed to pick the right (by that point, the only) handler. This added to the confusion.
The main problem with screenshots is that it doesn’t work well with searching or accessibility. My vision is working so I can decipher your screenshot.
I think the issue might be this code:
{ getProducts :: as :- Get '[JSON] ProductResponse,
getPromotions :: as :- Get '[JSON] PromotionResponse
It looks like the routes don’t actually differ even though they have different handlers. I think this is why the cookbook is using strings in the type of the example.
I think what you’re doing now is effectively saying “I have a GET endpoint A at path /, and I have a GET endpoint B at path /”. You probably have to make either the HTTP verb or path component differ.
You must be right! That makes complete sense. So my API’s definition isn’t even appropriate.
Thanks for the link to the docs, I had only found bits and pieces about the record api!