bct

There's no need to be sarcastic.

Could it go further, and do a better job of encouraging people to use REST? Sure. But it's trying to be pragmatic, and right now we're dealing with a world where people think that their unwillingness to learn is an argument against an architectural style.

Yes, we should be angry. But we should also check the assumptions that led us to misplace our trust.

The "error" function returns a struct containing the error string. I suspect the intention is to allow dynamically constructed error messages like "syntax error at line 4, char 3" (although it doesn't seem to be doing this anywhere). Since the string might be dynamically allocated, it has to be freed when the struct is freed, which obviously can't happen if the struct just has a pointer to the literal in static memory. (You could flag the string somehow as "should be freed/should not be freed", as you suggest in your other comment, but this has its own tradeoffs)

If you wanted an "error" function that would take string literals directly (and only string literals) you would do something like this: https://gist.github.com/bct/6300740

The "parse_ident" function doesn't return any portion of the input string, so it can just use a borrowed reference.

Voting/not voting/protesting/etc. are tactics that are only useful as part of a larger campaign, and as part of a large group committed to a particular goal.

"HTTP/1.1 does not define how a PUT method affects the state of an origin server."

I don't think it was ever the design or intent of PUT to store the exact representation that you gave it, and I would be surprised to see evidence otherwise.

Conceptually it's no different from POSTing (or PUTting) application/json to produce a resource that will be represented as text/html. How do you convert JSON to HTML? Depends on the service.

(And GET/POST/PUT/DELETE isn't CRUD.)

TimBL and the W3C were pushing for new payment models 15 years ago (and probably earlier). This is why HTTP has 402 Payment Required. There was a W3C micropayments working group back in 1998: http://www.w3.org/ECommerce/Micropayments/ .

This stuff would be hard to get right in a vacuum. It's even harder when you're trying to get groups with competing interests to agree on something, especially when you have as little leverage as standards organizations tend to have. The view put forward in the last half of this essay is naive.

That's extremely debatable.

(But yes, I agree that "turn this already-existing thing into JSON just because" is a stupid trend.)

It's not an ad hominem, it's an insult.

You should stick to subjects you actually know something about.

> Mutable state makes reasoning about program behavior more difficult than necessary.

You could dispute that claim, but bringing up performance characteristics is totally irrelevant to it.

Don't expect it to happen soon - we can't even make big self-replicating machines yet.

We don't even know what machines would look like at such a small scale. Structures behave very differently than they do at human scale; fundamental components like ropes, gears and pulleys might not be possible.

And then there's the problem of programming these machines; you can't exactly put an AVR inside them.

The browser doesn't retrieve the resource, it returns a representation of the resource. A map centered on a location is a valid representation of a resource identified by an address.

Not by any meaningful definition of REST.