Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

API Practices If You Hate Your Customers

queue.acm.org

Post reply on HN
Print view View original

141–150 of 258 posts

Re: API Practices If You Hate Your Customers

#141

Post by yjftsjthsd-h »

hnick wrote: post #80
tomaszs wrote: post #26

Personally i think API should be obligatory. Every company should provide it with respect for private data. Additionaly if a company does not have it, it should be prohibited to block automatic measures to process the system and data. There should be a pricing model to cover basic expenses made by the API usage. Maybe you wonder why on earth it should be legally allowed to process automatically system data? We have a…

Does "every company" include the thousands of local businesses running Woocommerce or Shopify? Larger companies love regulations like this because they can afford it, and it keeps smaller competitors from ever growing to be a threat. I'm not saying they should be able to do whatever with data - but for such providers, manually replying to an email is preferable than implementing a complicated technical solution they…

That's fine. The second point was precisely that if the company doesn't want to provide an API, fine; but they then don't get to try and stop people from scraping it instead. And I agree with my sibling comment; Woocommerce or Shopify or whatever just build it in like everything else they provide.

Re: API Practices If You Hate Your Customers

#142

Post by yjftsjthsd-h »

paulddraper wrote: post #57
tomaszs wrote: post #26

Personally i think API should be obligatory. Every company should provide it with respect for private data. Additionaly if a company does not have it, it should be prohibited to block automatic measures to process the system and data. There should be a pricing model to cover basic expenses made by the API usage. Maybe you wonder why on earth it should be legally allowed to process automatically system data? We have a…

LinkedIn would like to have a word with you.

LinkedIn is a worked example of why we need such a law.

Re: API Practices If You Hate Your Customers

#143

Post by yjftsjthsd-h »

musicale wrote: post #107

I guess that explains why the ACM Digital Library doesn't have an API. Even worse, they seem to forbid any sort of programmatic access in their ToS.

API practice number one if you hate your users: Don't provide one, and then ban them from working around the gap:D

Re: API Practices If You Hate Your Customers

#144

Post by hnick »

yjftsjthsd-h wrote: post #141
hnick wrote: post #80

Earlier quoted context omitted.

Does "every company" include the thousands of local businesses running Woocommerce or Shopify? Larger companies love regulations like this because they can afford it, and it keeps smaller competitors from ever growing to be a threat. I'm not saying they should be able to do whatever with data - but for such providers, manually replying to an email is preferable than implementing a complicated technical solution they…

That's fine. The second point was precisely that if the company doesn't want to provide an API, fine; but they then don't get to try and stop people from scraping it instead. And I agree with my sibling comment; Woocommerce or Shopify or whatever just build it in like everything else they provide.

Agree re: scraping, I was more stuck on "obligatory" so I guess I glossed over that.

I also agree that the big players would roll it into their core offering which would make life easier, but I'm wary of monocultures. A lot of people are already a bit annoyed at how much Wordpress is out there and this would just be another reason to skip a smaller (or bespoke) alternative and raise the barrier of entry for anyone thinking of making an alternative. But if we're agreeing that no one is forced to do it and scraping is OK, that's fine.

Re: API Practices If You Hate Your Customers

#146

Post by toast0 »

Fradow wrote: post #32

I was totally expecting to see something about using a protocol in an unexpected way, because "the protocol is not good enough". I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors. When pointed out, the support answer was "we chose to give meaningful er…

> I had to work with an API where the company decided everything should return http code 200 (well, at least all 4XX errors), and give the error code in the JSON response, mixing existing 4XX errors and their own errors.

If all of your errors line up perfectly with HTTP, I guess this could work. But if you've got something that doesn't fit, or two things that would map to the same one, it gets weird.

And then you have http client libraries that do great things like only return response bodies if status 200, or only return http statuses they were aware of. It's not very RESTful to just return http 200 with an embedded application status, but it's easy and consistent, and I would not write an HTTP api otherwise, unless I was had a good reason to follow some existing spec that used statuses.

Re: API Practices If You Hate Your Customers

#147

Post by thaumasiotes »

Ididntdothis wrote: post #137
thaumasiotes wrote: post #125

Earlier quoted context omitted.

If you don't know that "results" is an array... how do you handle the uncontroversial case of getting back an array of two results?

I know that but the PHP deserializer doesn’t know and gives me back an object instead of an array of one. If it’s two it detects an array.

But it's always a single object. If it has two parallel nodes at the document root, it isn't valid XML.

So an array of two results looks like this:
and PHP automatically treats results as a two-element array, but for the one-element array
you just get a parse error?

Re: API Practices If You Hate Your Customers

#148

Post by ako »

akurtzhs wrote: post #5
gtsteve wrote: post #2

I was expecting to see two of my pet hates - returning a null array to represent no items, and returning a single object without an array to represent one item. I also once worked with an API where you had to send the data in POST format - abc=123&def=456. After much pressure from their customers, they finally relented and added an XML version of their API... where your request could look like this: abc=123&def=456 .…

returning a null array to represent no items To be honest, that's what I'd expect. What do you dislike about that result, and what would you prefer to see returned? Jump straight to 404? returning a single object without an array to represent one item. So an array if there's multiple results, and a bare object for a single result? That's unpleasant.

404 indicates an error, if the result is just empty but not erroneous 204 "no content" may be better.

Re: API Practices If You Hate Your Customers

#149

Post by Ididntdothis »

thaumasiotes wrote: post #147
Ididntdothis wrote: post #137

Earlier quoted context omitted.

I know that but the PHP deserializer doesn’t know and gives me back an object instead of an array of one. If it’s two it detects an array.

But it's always a single object. If it has two parallel nodes at the document root, it isn't valid XML. So an array of two results looks like this: and PHP automatically treats results as a two-element array, but for the one-element array you just get a parse error?

Not a parse error but a single “result” object, not an array of length 1. With two elements it recognizes an array.

Re: API Practices If You Hate Your Customers

#150

Post by thaumasiotes »

Ididntdothis wrote: post #149
thaumasiotes wrote: post #147

Earlier quoted context omitted.

But it's always a single object. If it has two parallel nodes at the document root, it isn't valid XML. So an array of two results looks like this: and PHP automatically treats results as a two-element array, but for the one-element array you just get a parse error?

Not a parse error but a single “result” object, not an array of length 1. With two elements it recognizes an array.

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 "results" object, then you're saying that your code is written to require invalid XML and fall down when valid XML is provided. Again, that sounds more like a problem with your code than with the modeling capabilities of XML. There's an argument to be made for accepting invalid input; rejecting valid input is ridiculous.

Post reply on HN