Comment by therealwardo
16 hours ago
I really want to love this, but my experience in the first 20 seconds is unfortunately like some of my other experiences coding against Fly APIs, they're broken.
https://sprites.dev/api has this command:
$ curl -X POST "https://api.sprites.dev/v1/sprites" \ -H "Authorization: Bearer $SPRITES_TOKEN" \ -d '{"name": "my-sprite"}'
which responds with
{"error":"name is required"}
if you use the request body in the full "Create Sprite" documentation at https://sprites.dev/api/sprites#create then it does work.
can I live with some rough edges for some personal workflows that only impact me when things break? sure. however, I was thinking about playing with some CI/CD stuff using sprites that would impact our whole team if things broke and I'm really on the fence because of this experience in the first 20 seconds.
Fly team - please put some black box probes or just better testing on the example you give in the quick start. if you document it, test it.
Believe it or not, that's the only example that's not autogenerated from tests (yet).
https://github.com/superfly/sprites-js/tree/main/examples https://github.com/superfly/sprites-go/tree/main/examples https://github.com/superfly/sprites-py/tree/main/examples https://github.com/superfly/sprites-ex/tree/main/examples
Probably because you didn't include the content type header?
yep that would fix it. just needs a little docs change.
a "quick start" really should just work when you copy paste them.
why does an API that only accepts json need me to specify in a header that it’s json.
just assume it’s json. you’re gonna parse and validate it anyway.
If it turns out that someone is willing to pay for some other protocol then they just have to hook it up to that MIME type and start serving. It might be possible that they can derive an implementation of that protocol from their data schemas.
If they hardcode JSON such a change would be breaking for their previous users.
Can it be some other content type?
Can this issue be reported?
I wish more companies had open issue trackers (some proprietary software have issues on Github for example, but, it doesn't need to be Github, just let people discuss issues in the open)
The documentation is correct now. I assume someone from fly is reading the comments.