Piatro@programming.dev
on 12 Dec 22:32
nextcollapse
The fact Microsoft isn’t mentioned astounds me.
chaospatterns@lemmy.world
on 12 Dec 23:44
nextcollapse
It just goes to show the small parts of API design matter just as much as the big parts. I’ve worked with a lot of engineers who are so eager to draw big boxes and arrow architectural diagrams, but then just rush the details because that’s not important.
A big part of my job is API integrations. The most infuriating one I deal with is a startup who keeps adding new properties with property names randomly being pascal case, camel case, or snake case. Especially when the same property is one case on a request model and different on the response.
chunkystyles@sopuli.xyz
on 13 Dec 14:20
nextcollapse
BatmanAoD@programming.dev
on 13 Dec 03:11
nextcollapse
The spec requires errors to be a single string, and also mandates using the space character as a separator? I’m not a fan of deviating from spec, but those are…bad choices in the spec.
chaospatterns@lemmy.world
on 13 Dec 03:53
collapse
The spec mandating its as a single string isn’t that crazy. It’s good to have a consistent response format so a basic deserializer can deserialize any error response object and get something out.
If you have different providers. One that returns error: { code: string } and another does something else, you end up with the same problem this post talks about-- Inconsistency.
As far as I can tell, the spec doesn’t limit you to just the one field and you can add other optional fields to the top level to the response that the caller can optionally decide to handle. But if you know there’s going to be a field called error that is a string. You always get at least something out of that to present.
BatmanAoD@programming.dev
on 13 Dec 19:30
collapse
Yeah, consistency is good, which is why it’s good to follow the spec. I’m saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where code is nested one level below error, plus permitting extra implementation-defined fields in that object.
Having dealt with a few it seems nobody really cares about specs and just implements something that returns a token.
The result is you end up doing a load of work every single time and none of that can be used for anyone else’s implementation.
I get the idea of oauth, but the implementations needed a whole lot less wiggle room, because it turns out when you’re a massive corporation every other poor bastard just has to adapt to your nonsense.
Same. Ive had to create a couple of custom API wrappers and each one is significantly different especially with oauth. But it almost always comes down to getting a temp token, do a thing for a time, get another temp token, so on so forth.
threaded - newest
The fact Microsoft isn’t mentioned astounds me.
It just goes to show the small parts of API design matter just as much as the big parts. I’ve worked with a lot of engineers who are so eager to draw big boxes and arrow architectural diagrams, but then just rush the details because that’s not important.
A big part of my job is API integrations. The most infuriating one I deal with is a startup who keeps adding new properties with property names randomly being pascal case, camel case, or snake case. Especially when the same property is one case on a request model and different on the response.
That’s infuriating. I’m angry for you.
Worst-case scenario.
This unhinged tone is what I live for in blog posts
Edit: added hyperbole to make humourous intent clearer
…mataroa.blog/…/i-will-fucking-haymaker-you-if-yo…
The spec requires errors to be a single string, and also mandates using the space character as a separator? I’m not a fan of deviating from spec, but those are…bad choices in the spec.
The spec mandating its as a single string isn’t that crazy. It’s good to have a consistent response format so a basic deserializer can deserialize any error response object and get something out.
If you have different providers. One that returns
error: { code: string }and another does something else, you end up with the same problem this post talks about-- Inconsistency.As far as I can tell, the spec doesn’t limit you to just the one field and you can add other optional fields to the top level to the response that the caller can optionally decide to handle. But if you know there’s going to be a field called error that is a string. You always get at least something out of that to present.
Yeah, consistency is good, which is why it’s good to follow the spec. I’m saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where
codeis nested one level belowerror, plus permitting extra implementation-defined fields in that object.Having dealt with a few it seems nobody really cares about specs and just implements something that returns a token.
The result is you end up doing a load of work every single time and none of that can be used for anyone else’s implementation.
I get the idea of oauth, but the implementations needed a whole lot less wiggle room, because it turns out when you’re a massive corporation every other poor bastard just has to adapt to your nonsense.
Same. Ive had to create a couple of custom API wrappers and each one is significantly different especially with oauth. But it almost always comes down to getting a temp token, do a thing for a time, get another temp token, so on so forth.