zlacker

>>usrme+(OP)
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.

>>therea+AX3
Probably because you didn't include the content type header?

>>tvink+d34
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.

>>ch2026+2b5
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.