Evert Pot

And there's something to be said for batching -- if instead of requesting each resource individually, you ask for all of them simultaneously, the backend can see that context and fetch that data more efficiently.

In something truly RESTful (with HATEOAS and media types and all that jazz), the links between resources are only discoverable dynamically, and the client traverses that resource graph interactively. As the article explains, that works a lot better when you aren't scared of the per-request network overhead. But it still fundamentally limits the amount of context provided to the server on each interaction, preventing the server from optimizing for each request beyond guessing and pre-fetching what it thinks a client will need. (And the pre-fetched data has to live somewhere, meaning you've just created a cache and all its concomitant issues.)

Taking GraphQL as an alternative, the resource graph is statically known -- you can effectively fetch the schema just once. You can then traverse through many resource relationships and fetch many disparate units of data in a single request, and the backend can see that structure and decide how to efficiently gather all of that data.

Even besides the interaction context, doing REST properly (instead of a faux-REST actually-RPC HTTP API) can be pretty challenging. How many REST APIs are founded on media types instead of statically-determined URLs and methods? [0] If you're just doing HTTP RPC, you more-than-likely have a…

Here's the article in question. [0] I think runxiyu is correct.

The author delves a bit more into the issue.

> One of most obvious problems is that if you also tell curl to follow HTTP redirects (using -L or --location), the -X option will also be used on the redirected-to requests which may not at all be what the server asks for and the user expected. Dropping the -X will make curl adhere to what the server asks for. And if you want to alter what method to use in a redirect, curl already have dedicated options for that named --post301, --post302 and --post303!

Per the man page (`man 1 curl`),

> The method string you set with -X, --request will be used for all requests, which if you for example use -L, --location may cause unintended side-effects when curl does not change request method according to the HTTP 30x response codes - and similar.

`-d` and `--data` will appropriately change the headers of their requests. Funnily, `--post301` and `--post302` which have a similar effect as `-X POST` are RFC 7231 compliant, browsers just don't do that. [2][3] This is so ubiquitous that the error codes 307 and 308 were added to support the original behavior of repeating the request verbatim at the target address. Compare the following:

> nc -l -p 8080 -q 1 <<< $'HTTP/1.1 301 Moved Permanently\nLocation: http://localhost:8081\n\n' & nc -l -p 8081 -q 1 <<< $'HTTP/1.1 200 OK\nContent-Length: 0\n\n' & curl -L --data test localhost:8080; wait > nc -l -p 8080 -q 1 <<<…

This blog post sums up my feelings on LinkedIn pretty well:

https://evertpot.com/10-years-of-linkedin/

My only issue is that I feel, as an independent contractor, I’m obligated to maximize my potential in acquiring new customers. I don’t yet have the luxury to shut down an entire channel for new leads, despite the fact that LinkedIn has actually done very little for me in that regard. On top of that LinkedIn has become so ubiquitous that it’s actually become a standard question during some interview processes to ask for my profile. I feel that “I don’t have one” because of “principles” is never a great opener when you just made a new connection with someone.

The only other real tangible benefit I get from it is knowing about job changes my friends have made. I'm in my mid-30s and most of my good friends from University are spread across the continent. I'm lucky if we talk to each other a few times a year. So having the ability to passively learn "Oh hey, Jonny is now at Google" is valuable to me because I now know I have good contact at Google.

Not at all.

AS1 was plain ES3.

movieclip._x or movieclip._alpha (as in position and alpha blending) were accessed by properties with underscore to denote that you were using accessors (getters/setters).

Internally properties like Object.prototype.__proto__ had two underscores to denote they were private.

In AS2 you had:

class Foo extends Bar implements Xyz { private foo public function set x (value : Number) : void { ... } public function get x () : Number { } AS2 was based on long forgotten ES4 specification [0]. Under the hood it was still, what we would call today, transpiled to ES3 bytecode, as it run basically on the same VM as AS1.

It's crazy to think it took us 10 years to reinvent the wheel with TypeScript.

AS3 was a complete rework, more akin to Java.

[0] https://evertpot.com/ecmascript-4-the-missing-version/

related: http://evertpot.com/dropbox-post-api/

Basically everything about the status quo is messed up.

JSON into parameters: bad.

JSON into request body: undefined with the GET method.

JSON into request body with POST: great, but we're not actually mutating anything, so it's bad practice and won't be cached by varnish/nginx + a barrage of other problems.

I really wish someone would take up on http://www.ietf.org/rfc/rfc3253 - like REPORT as an analogue to GET, just with a JSON request body. Hey, we as a community finally managed to get PUT and PATCH on track, why not this one?

Debian policy is very sane (no network access during build), but it does seem like modern software just assumes that the Internet is always available, and all dependencies (including transitive) are out there.

The assumption is a bit fragile, as proven by the the left-pad incident ([1]). I hope that whatever the outcome of the discussion in Debian will be, it would keep the basic policy in place: not relying on things outside of the immediate control during package builds.

1. https://evertpot.com/npm-revoke-breaks-the-build/