API Practices If You Hate Your Customers • Hacker News Board

Re: API Practices If You Hate Your Customers

#241

Post by thaumasiotes » Fri, Dec 13, 2019, 6:49 AM UTC

vaidhy wrote: post #202

thaumasiotes wrote: post #150

Earlier quoted context omitted.

If you can parse and you end up with a single "result" object, you must have identified "results" as being an array of one element so that you could discard it. (You didn't get a single "results" object.) That's not a problem in what XML is able to model, it's a problem with you throwing the information you got away and then pretending you didn't receive it. On the other hand, if you meant that you get a single "resu…

You do understand that php and quite a few other languages provide pre-built serialization and de-serialization from XML, right? The OP was talking about the out of box behaviour for those. Your answer seems to predicate on having written a custom deserializer.

My answer is predicated on the idea that you should be using a deserializer that doesn't rely on receiving invalid input, regardless of whether that deserializer comes from a standard library.

Re: API Practices If You Hate Your Customers

#242

Post by aganame » Fri, Dec 13, 2019, 9:00 AM UTC

dx87 wrote: post #34

tbirdz wrote: post #24

Earlier quoted context omitted.

I really don't like your story. The junior is clearly behaving immaturely and inappropriately by CCing others and not using an appropriate tone, but your response is to... retaliate by doing the exact same thing to him? What lesson is the junior supposed to learn here? That acting that way is A-OK as long as you have seniority and are factually correct? At least the junior has the "excuse" of being a junior, but real…

I'm not seeing anything wrong with what OP did. By CCing everyone, the junior is trying to make themselves look good by making OP look bad. The junior learned that if they act like an ass, especially an incorrect ass, the other employees won't tolerate it.

It wasn't wrong, but it also betrays that OP wasn't really a senior either. Just an older junior.

Re: API Practices If You Hate Your Customers

#243

Post by arethuza » Fri, Dec 13, 2019, 9:25 AM UTC

perl4ever wrote: post #239

arethuza wrote: post #168

Earlier quoted context omitted.

Unfortunately I have vivid memories of one API I worked with (many years ago) that included entire encoded XML documents as attribute values within top level XML. At least there was only one level of recursion. Still, perhaps not as bad as using XML documents as database keys...

A common misconception is that you can put anything in xml via CDATA so long as it doesn't have the ending delimiter embedded. https://stackoverflow.com/questions/21087648/xml-invalid-cha... I know about this because I received a file with illegal CDATA characters once.

Receiving XML that is almost valid can be a real pain - it certainly used to be that some XML parsers didn't report some weird errors in a particularly helpful way requiring manual scrutiny.

I have unpleasant memories of trying to work out why some SOAP web service was breaking and it turned out the WSDL was invalid in a subtle way.

Re: API Practices If You Hate Your Customers

#244

Post by Piskvorrr » Fri, Dec 13, 2019, 11:18 AM UTC

sangnoir wrote: post #236

donkeyd wrote: post #177

Earlier quoted context omitted.

I worked with a product for natural language processing that wanted the text in a query string. This led to 100+ page documents begin sent as a string in the request. My usual REST testing app would freeze up if I wanted to test some of the largest documents in the data set.

> This led to 100+ page documents begin sent as a string in the request How were you able to do this when the standard maximum length of a query string is 1024 bytes? I guess you could flaunt the standard as you were responsible for the backend

Except that standard...isn't. It's what some ancient version of MSIE did and that used to count for a standard in Triassic; nowadays, it gets passed around as cargo cult advice. (The relevant RFC recommends no more than 8000 bytes, sure.)

https://stackoverflow.com/questions/417142/what-is-the-maxim...

Re: API Practices If You Hate Your Customers

#245

Post by lowercased » Fri, Dec 13, 2019, 2:26 PM UTC

ergothus wrote: post #235

lowercased wrote: post #216

Earlier quoted context omitted.

There's no way to know in advance what someone will learn from an experience. You also don't know what they learn 'now', and what they might reevaluate and relearn years from now about that same situation. Basing your response decision primarily around what someone might learn isn't a great way to decide how to respond. Couple folks I'm working with right now, and I had thought a couple of times "well, this wasn't a…

> There's no way to know in advance what someone will learn from an experience. Correct. You can, however, improve the odds. Being explicit about what you want them to learn as opposed to expecting a certain degree of interpretation cannot hurt your odds, though it can't guarantee them. > Basing your response decision primarily around what someone might learn isn't a great way to decide how to respond. In this contex…

> what else was the point of the response?

some other public reaction/recognition for the OP, not for the benefit of the original sender.

emotional venting? that's sometimes its own reward.

Re: API Practices If You Hate Your Customers

#246

Post by MadWombat » Fri, Dec 13, 2019, 7:03 PM UTC

tlb wrote: post #51

MadWombat wrote: post #46

> An operation is idempotent if performing it multiple times yields the same result as performing it exactly once. And then he casually offers an API that does different things on first and second call as the "good" example. If you have a "create a virtual machine" API it better create a fucking virtual machine. If I call the damn thing twice, I expect to have two VMs. If there is some sort of unique argument like cr…

The idempotent operation is usually "Ensure that a VM exists with this name and spec". An advantage of this style is that if the client dies or times out during the (long) operation, it can retry and get the same answer instantly.

What happens if some other process has already created a VM with this name and spec? Under most realistic scenarios I would rather VM creation failed than silently clobber someone else's VM.

Re: API Practices If You Hate Your Customers

#247

Post by sho » Fri, Dec 13, 2019, 7:21 PM UTC

jayd16 wrote: post #228

sho wrote: post #180

Earlier quoted context omitted.

404 and 500 should come from the destination server. You are correct that 503 would not.

Hmm are these assumptions valid? Can't a misconfigured load balancer cause a 404? Couldn't a bug in nginx, node or an app server produce a 500 response outside of your control?

I suppose a misconfigured load balancer or nginx instance could return absolutely anything. I think you'd have to be actually maliciously misprogramming it, though, to reach that level of dysfunction!

Re: API Practices If You Hate Your Customers

#248

Post by enz » Fri, Dec 13, 2019, 10:18 PM UTC

I used to work in a company like that almost all techniques described in the article were in use.

Turns out it doesn’t piss only customers but developers (of the API) as well.

Re: API Practices If You Hate Your Customers

#249

Post by AgentME » Sat, Dec 14, 2019, 6:35 AM UTC

Glyptodon wrote: post #133

AgentME wrote: post #103

Earlier quoted context omitted.

POST isn't required to be idempotent, but to be clear it's not improper to make an API with idempotent POST endpoints.

Which is exactly why it's a fairly unusual choice for an example.

It would be weird if he used a method like GET which is normally idempotent. People already make those be idempotent, so they would miss that the point is that a good API has all idempotent endpoints, POST and not.

Re: API Practices If You Hate Your Customers

#250

Post by yencabulator » Sat, Dec 14, 2019, 11:36 PM UTC

lilyball wrote: post #234

simiones wrote: post #208

Earlier quoted context omitted.

As explained in the thread, that is because Go best practice is to treat `nil` and `[]T{}` as the same thing in every API. If you want an explicit `null` in your JSON you can use `*[]T` as your field type, and then it makes more sense. The very idea of allowing the nil value for slices seems to be very strange and inconsistent, as slices are struct types, not pointer types in Go (they contain a pointer and other memb…

It is admittedly very weird that Go supports nil slices/maps instead of just having the nil value be an empty slice/map that points to constant storage. But as long as Go has a semantic difference internally, representing that as null externally makes sense. Though I suppose as long as the conversion from null to empty array/object is opt-in it's fine. For context, we recently had a bug where backend forgot to initia…

The nil value for a slice is an empty slice that points to constant storage: Data=0, Len=0, Cap=0. That's just not the same as Data=somethingelse, ... which you get if you allocate something.

(And all Go zero values are exactly what you get with the relevant RAM filled with the zero byte.)