Bring Your Own Client

Extending the analogy to absurdium, should (CompanyX/Twitter) be allowed to have ToS against a (browser extension/etc) which would reduce it's revenue to $0, and theoretically force it to shut down and lay off all the (engineers/employees)? If no, what rights does Twitter have to decide alterations to it's product if any, and where do they begin? If yes, who makes that decision: a government, a regulatory body etc?

What if the ToS said "don't circumvent our API rate limiting" and someone made a browser extension doing just that. Is it okay to have it in the Google chrome store? If it got in, should it stay up?

Note, against my points, the Supreme Court decision on scraping in the LinkedIn case.

It shouldn't be that hard to do. You may need maybe 5 endpoints. Get all product data for the whole stock, get individual product images, get order requirements (can include terms and conditions, desired information for the order, payment options, human contact info, etc.), post an order, get order status.

On this API you can easily create a fully featured 3rd party online shopping clients. Some shopping experiences these days are atrocious.

Some hugely popular platforms have product lists hidden like 4 screens bellow the fold, separated by tons of crap, that just gets in the way. Category selection is placed such, so that categories slide away, when you get to the product list after selecting one of the categories, and if you want to switch category, you just have to scroll all the way up again. No options for selecting alternative views, like in a file manager (large icons with a ton of detail, list view, etc.)

Each new eshop you have to learn how to navigate it, and collecting information about the ToC and payment/delivery methods is a hassle.

Could be so much better if there was some simple web protocol for this, and it could be exposed in addition to existing website, too.

In the simplest implementation, everything but the POST could just be some static json files uploaded to the http server. And POST /order could just be sending an e-mail to someone.

It’s a music locker service with a custom web client. Instead of writing my own native app I implemented the Subsonic protocol: http://www.subsonic.org/pages/api.jsp

It’s awesome to have a polished native app for “free” (eg. play:Sub on iOS is really nice) but it’s such an underspecified and loose spec that implementing it was a huge pain in the ass. For example, clients will choke on results missing values that are specified to be optional in the spec. The spec imposes integer offsets for pagination but my database wants string continuation tokens. It’s specified as XML but there’s an option to make it JSON with zero information on how to deal with discrepancies. Some clients use GET, some POST, some mangle the URL or capitalize random paths. I just had to reverse engineer pre-existing servers to figure out what clients can handle and there’s still a few clients that are mysteriously broken. I’m going to have to test as many as possible and create a list of recommended ones.

I’m happy I went with BYOC but I highly recommend to plan for it from the start so you can deal with the protocol’s weaknesses sooner than later.

It is not: https://en.wikipedia.org/wiki/SIM_lock#European_Union

Last time I was looking for a phone (~8 years ago), in France, I had to check which ones were simlocked.