Live data from Hacker News

API Practices If You Hate Your Customers

queue.acm.org

191–200 of 258 posts

Re: API Practices If You Hate Your Customers

#191

Earlier quoted context omitted.

I'm curious, what tech stack are you working in where parsing json is difficult? You want to talk about inconsistent? How about a 500 error may or may not result in the standard response format you're expecting because it may be coming from the server and it may be coming from the API. I'd much rather my 500 errors be legitimate server problems.

While we're asking questions: what stack out there makes reading/writing HTTP headers hard? Because that's all it takes to work with response codes. And yes, of course parsing JSON isn't difficult. Note that I said parsing messages -- the message field not the response body. And parsing that message field and checking conditionals to determine your client's behavior is something you'll have to write code for unless y…

> And parsing that message field and checking conditionals to determine your client's behavior is something you'll have to write code for unless you're just relaying the error message back to the end user.

Oh noooo, you have to.... handle errors coming out of API's you consume. What an imposition... It must be terrible to be you, always having to write code to handle when things don't go exactly down the happy path.

> Might be better to have the HTTP error code and prepare your client to read responses based on multiple content types.

yes! Imagine seeing a 500 and knowing for sure that there's a server misconfiguration. Being able to trust http status codes: it's what's for dinner.

Re: API Practices If You Hate Your Customers

#192
post #189

"Technique #5: Use a terrible protocol Debugging is boring. Wouldn't you rather appeal to customers who write bug-free code on the first try? To really show disdain for your customers, use a proprietary protocol so that language support is limited to the client libraries you provide, preferably as binary blobs that are never updated. If you design it carefully, a proprietary protocol can be difficult to understand an…

That's a bit of a strawman. The cultural tradeoffs between "inspectable" JSON and "bloated" SOAP have to do with their most common consumption environment.

In my current life I work mostly with JSON and a typical workflow involves checking API documentations, querying the endpoints, and understanding the structure. I need to own the mapping between JSON and domain objects.

In a previous life I worked with .NET and C#, mostly SOAP APIs. A typical workflow involves right-clicking somewhere, pasting the link to the SOAP endpoint's WSDL file, and automagically getting a collection of strongly typed classes that I can manipulate directly and operate on as if they were domain objects.

The idea that when using SOAP one spends any time (manually) parsing and trying to make sense of XML is a misconception.

To put it in a modern parlance, one shouldn't compare SOAP to JSON. SOAP is JSON + Swagger, with the Swagger integration costing 0.

Re: API Practices If You Hate Your Customers

#194

Earlier quoted context omitted.

If under your suggestion you have to look at the details of a 404 anyway to get a detailed error message, what is the point of the 404? Your client always has to do an explicit check for error/no-error. Why make them check two different locations? Just always look at the body: one location.

You don't have to. Plenty of times, a 404 is all I need to know. Why make the client check two different locations?

Because they can pull extra information out that can help them understand why they're receiving a 404. The lack of information can itself become a signal.

Re: API Practices If You Hate Your Customers

#196

Earlier quoted context omitted.

I had this happen with a vendor that was told that they needed to add REST support to their legacy Java app. They turned up with an API that encoded XML as base64 and put that in a POST variable on HTML page. Then they added their own crypto on top with hard-coded RSA keys. They helpfully included both the public and private keys in their documentation. When they turned up for a meeting to present the fruits of their…

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...

I saw that in HTML. Not from a professional developer but it still blow my mind. That was the final straw that made me quit the project.

Re: API Practices If You Hate Your Customers

#198

Ha! Anybody who implemented a payment processor on their side of the fence to interact with Visa/Mastercard on the other side will have seizures while reading this article. Those API's are definitely written with "hate your customer" practices in mind.

Ooh yeah. If you have ever integrated with Vantiv you will know what all this means. Heavy lifting is on the customer side. What a pain

Re: API Practices If You Hate Your Customers

#199

Earlier quoted context omitted.

A polite response does not have to be a meek response. You can be blunt, you can point out all the problems, while still being polite. That also has the advantage of being 100% clear. "You just told hundreds of people my code is poor. You attacked me, and my professional reputation, and you did it inaccurately. This gives me little reason to respect you or want to help you. Asking without copying the world and withou…

I've gotta say, if I was a third party to the exchange that involved your suggested message I would think the senior developer was a pompous and condescending ass. In the UK we (or at least I) wouldn't consider what you wrote to be a polite response.

Funnily enough, my last team worked with a software supplier from the UK, and I’m 99.99% sure the above text was copy-pasted from an email reply to one of my overzealous team members. We thought it was over the top, but chalked it down to British culture
Post reply on HN