Reddit's April Fools' experiment - <AUTHOR> https://arstechnica.com/gaming/2017/04/in-memoriam-reddits-72-hour-live-graffiti-wall-as-a-social-experiment/ <comment><USER3> I think this was a pretty neat experiment. For the first 24 hours everything was chaos, then it settled down in the middle as communities formed, then at the end it was just annoying as every subreddit was trying to take over real- estate, and far too many people were taking it way too seriously. It got annoying going to certain subreddits that I subscribe to for content started getting flooded with "Man the decks, we need to defend this!".

The other thing this author tried to make this about was politics. I think the one thing this really showed was most people on reddit don't really care about politics, but the vocal minority on there makes it seem like it's the forefront of every issue. I don't think there is anything actually political on the final /r/place piece other than country flags. Maybe this was more about how disinterested the majority of redditors are with politics rather than how politics were being squashed out by other users?

<comment><USER4> There was another fascinating aspect of politics that sprang up due to Place: inter-community politics.

My community (Madoka Magica) was continuously communicating with our neighbors on all sides, ranging from the gigantic PrequelMemes to our right, Canada to our south, Homestuck, the Greek and Turkish flags mentioned in the article (which really were warring for quite a time before the heart appeared), and even tiny little subreddits like the AEIROU who we had to relocate as part of negotiations for our expansion.

There was constant debate about where to expand, who to defend against, who was being a jerk and needed to be wiped out... it was like a game of Diplomacy more than anything else.

<comment><USER5> /r/wales and /faroeislands had a mutual defense pact, enabling both (small in terms of Reddit) communities to punch above their weight.

It was great fun, fighting off trolls and attempts by other subreddits to aquire further real estate for themselves.

/u/SCtester cleaned up the final image to fix up (ed: some of) the in-progress and rogue pixels and damage by the "void" group.

[http://i.imgur.com/7E3bAnE.png](http://i.imgur.com/7E3bAnE.png)

There are several errors in his fixup, "Hypercum" being an example. /r/Scotland got lucky at lock-time, they came closer to being Scatland.

<comment><USER6> Reading through the conversation on this stuff, I'm wondering if this weird combination of amusement and befuddlement is how my parents felt when I was telling them about my online activities back in the early 90s.

<comment><USER7> Wait until you hear about how 4chan's My Little Pony and Politically Incorrect(read: Nazis) became friends after this year's April Fools prank.

</comment></comment></comment></comment></comment><comment><USER8> It's worth nothing that the admins did actively ban users trying to make swastikas. /b/ tried and found that out the hard way. Reddit's content policy[1] was still applicable and was very much enforced.

[1] [https://www.reddit.com/help/contentpolicy/](https://www.reddit.com/help/contentpolicy/)

<comment><USER9> When are we going to see this beautiful sign back in our culture as a positive symbol :( that and the Hitler mustache. I'm guessing we need a few hundred years before we can use these things without it being associated to Nazism.

<comment><USER10> You need to explain yourself better. You seem to be opposed to Nazism, but in favor of their symbol. Why?

<comment><USER9> I upvoted you because it is sad that ignorance is downvoted :(

<comment><USER10> My initial instinct was to down vote you, because (as we've discussed) Swastikas are synonymous with Nazism to many people, but on second reading it didn't seem like you were actually supporting Nazis so I decided I would ask. I also thought others might down vote you like I almost did.

I know I could have done a Google search and figured it out on my own, but if we're not allowed to ask questions which are already answered somewhere on the internet then I guess we wouldn't be asking very many questions.

</comment></comment></comment></comment></comment><comment><USER11> Reddit's AF this year was excellent, probably my favourite AF experiment of all time.

I usually really dislike AF on the internet - some (most) sites become completely unusable for a day and, last thing the internet needs, it gets even harder to tell real news from the fake bits. (Did you know Takei is running for 2018 congress? That was true! Actually it wasn't. But it was! Well, no, it wasn't.)

But I'm really fond of how Reddit always handled it: A day for creativity and experimentation. The Place is a really, really beautiful experiment and the result of it surpassed expectations.

<comment><USER12> I absolutely love AF on the internet. Yes, there will always be sites that produce low effort, boring and annoying content, but when isn't that true? On the other hand, you have plenty of companies and sites that produce genuinely funny and well thought out content.

Reddit has consistently been the best for the past few years. Google, Blizzard, Razer and a few other companies always produce a couple good videos too. I definitely agree with you though that creativity and experimentation is far more interesting than cheap little tricks.

<comment><USER13> Really enjoyed Ms pacman on google maps.

I prefer that than fake news.

</comment></comment></comment><comment><USER14> Someone's gotta mention [http://www.milliondollarhomepage.com](http://www.milliondollarhomepage.com) :

Early in the history of the Internet, some high school kid set up a web page with a 1000x1000 image and a limited color palette. He sold individual pixels, plus a link from that pixel to anywhere, for $1. Yup, he sold them all in fairly short order.

<comment><USER15> The sad thing is none of those logos and links have any meaning any more, almost all of them go to 404s, domain parked pages, or completely unrelated sites, and even when they were new they went to scummy ecommerce or porn sites. In 12 years, the imagery on /r/place will still hold meaning and the timelapses will still tell a pretty cool story.

<comment><USER16> Pretty wild to see a (relatively) huge company like 2checkout ([https://www.2checkout.com/](https://www.2checkout.com/)) on there.

<comment><USER17> It was an international news story and clearly still gets some attention (last time I was reminded of it was within the last year).

</comment></comment></comment></comment><comment><USER18> It was a seriously cool experiment. Factions rose and fell, alliances were forged, battles waged, "rules of war" developed. It was amazing.

But I don't think there's much to be gained from pontificating about it as a model for preventing hate speech.

For one, it was moderated. The slow speed of creating things just meant it was easier on moderators.

Secondly, the main thing that made it mostly pleasant was that only very widespread ideas could flourish. Minority ideas, whether good or bad, could not (even the art from small communities was only allowed to exist via alliances with larger communities that could easily destroy their art). This means things were mostly unobjectionable, but it also limits creativity. Do you really want that to be your model of public conversation? Things can only be published if 1000 people all try to publish the same thing and work to maintain it?

This would just be pushing filter bubbles to the extreme and driving resentment underground where nobody would notice it until it bubbled over. Then people would be like "whoa, where'd all the hate speech come from?", when it was there all along but not the dominant voice. And they would be making poor decisions regarding their own political strategy, because they mistakenly believed that they had won a battle that they had not.

All a model like that would do would be to amplify the status quo, whether good or bad. Just because your political faction happens to be dominant in certain circles doesn't mean you should adopt policies that always benefit the dominant political faction. Especially when your faction is all about protecting minorities. A status-quo-favouring policy would be terrible for minorities that do not already carry favour with the larger population.

When you think about whether a policy for shaping public conversation is a good idea long-term or not, consider whether it would be a good idea say, in Russia today. LGBT people in Russia are oppressed and do not hold favour with any larger political faction. "Majority gets to censor the minority" is a terrible policy in almost all cases, and people at present only don't realise this because they are in the historically improbable situation of the people with the power to censor also being the ones who favour minority voices. This is historically rare, and your policies should not rely on it being the case.

<comment><USER5> >Minority ideas, whether good or bad, could not (even the art from small communities was only allowed to exist via alliances with larger communities that could easily destroy their art)

I'd disagree. /r/wales and /r/faroeislands have less than 7k subscribers between us. We had no bots, just a few people in a Discord channel.

Actual: [https://i.imgur.com/GtkaGlJl.png](https://i.imgur.com/GtkaGlJl.png)

SCtester Cleanup: [http://i.imgur.com/GQCTigC.png](http://i.imgur.com/GQCTigC.png)

Wales also had our dragon beneath the main UK flag along with NI, England and Scotland. There was also a cool Wales places heart.

<comment><USER18> Sure but the heart was there at the pleasure of the heart people, and the dragon beneath the UK flag at the pleasure of the UK people. If either of them wasn't cool with wales, they could have gotten rid of them (I'm not sure about the other one but I suspect there were conversations and agreements with surrounding art not to expand into each others' territories).

Other, larger groups that did not have alliances with others failed to gain traction - Trump fans failed to draw Trump even though there are more of them than welsh people. Their numbers were large, but they did not have the favour of the majority.

The OSU people, though nobody had an opinion on them beforehand, did a poor job of diplomacy, and as a result really struggled to stay on the canvas.

It was about who was in the good books of the larger factions more than anything else. If rainbowroad or the germans liked you, you were golden. If OSU liked you, well, that wasn't worth much.

<comment><USER5> All the stuff in the image was by us, and we fought and won for the space.

Wales is fundamentally part of the UK, and I would assume the Welsh we were represented within the /r/unitedkingdom place team. We certainly are in the subreddit. That was more /r/unitedkingdom but /r/wales did some defence of it.

As for the heart in placehearts, that was r/placehearts and their allies more than us. (The Wales/Faroe Islands heart in the image was all us.)

I would speculate T_D failed in large part because they attacked areas that were defended by bots, they (correctly) prioritized the flag, and trolling others.

I'm sure it didn't help that they've antagonized the entire Reddit community with their shitty lack of reddiquette in general since their inception.

I'd go further and suggest a lot of their members were lost to the Void, which I'd cynically suggest overlaps significantly.

</comment></comment></comment></comment><comment><USER19> I love those kind of "get together and improvise" experiments. The last time I had felt such a sense of wonder and community was the first few days of Pokemon Go when everyone was in the street trying to figure it out.

There's an untapped concept behind all of those. Content that is ephemeral but brings a lot of people together...

<comment><USER20> A really great radiolab on the subject is their episode on Emergence: [http://www.radiolab.org/story/91500-emergence/](http://www.radiolab.org/story/91500-emergence/)

That's what /r/place was like in the first few hours, where people saw a pattern and just laid their pixel down to continue it, which is how you got things like a blue line (accelerating as time went on) and the blue corner. You as a contributor don't know what you're building, but as a group you build something.

Later as communities started planning and running scripts, it became much less "improv"-y.

<comment><USER19> "Emergence"! Thank you for the word. I was looking for it!

</comment></comment></comment><comment><USER21> I can't think of many examples, but I do like these sort of projects - <USER2> Plays Pokémon comes to mind. Interesting how an entire subculture can develop: inside jokes, wars, and more. It's amazing because it's a microculture, but it develops far faster than any "regular" culture would.

<comment><USER22> Other examples include the Bob Ross reruns and SeeBotsChat on Twitch.

<comment><USER23> You're thinking of this w.r.t. Bob Ross? [https://www.forbes.com/sites/laurenorsini/2015/11/02/how- dea...](https://www.forbes.com/sites/laurenorsini/2015/11/02/how-dead-painter- bob-ross-is-bringing-positivity-to-the-internets-most-cynical-community/)

<comment><USER22> Yep. Though it feels a bit strange to be reading a Forbes article about it. Seems more like the kind of thing you'd read about on Know Your Meme: [http://knowyourmeme.com/memes/people/bob- ross](http://knowyourmeme.com/memes/people/bob-ross)

</comment></comment></comment></comment><comment><USER24> Although I don't see it as much here on HN, but in real life and in other areas. I have seen some criticism that many felt it hard to believe that people could collaborate on this so well and they believe it was almost entirely bot driven or somehow belitte the effort. While I know towards the very end there were a growing number of bots and scripts that did start taking hold more.

Anyone who was part of it, even more so if they were engaged in discord or other more active channels than just subreddits, easily saw the hundreds of people collaborating, community, alliances, discussing ideas, and more. All of this together helped make it what it was.

I truly believe it was mostly done as a direct result of a lot of peoples' hard work and persistence. I participated in some large pieces; as well as helped promote/start a very small piece myself. All of it came together quite beautifully.

</comment><comment><USER25> This experiment reminds me of an old website where visitors only had so much paint (and it would slowly regenerate over time), and would paint portions of a common canvas. I can't remember the name of the site, but I think it was active in the mid 2000's.

Of course, at times 4chan would invade, but I think it was mostly eastern europeans present (as once again flags were the big thing to paint everywhere).

<comment><USER26> Drawball

<comment><USER25> This is exactly it! Thanks.

</comment></comment></comment><comment><AUTHOR> Hm. I agree the original title from the article was clickbait, but ... could it perhaps be titled something that emphasizes the cooperative nature? It's not really an April Fools' gag as much as a social experiment.

<comment><USER27> We'll s/gag/experiment/ above.

<comment><AUTHOR> Cheers :)

</comment></comment></comment><comment><USER28> My favorite moment of the experiment was when a German flag began to overtake a French flag, and as fighting was taking place over the former-French flag, France went upwards and made a flag, and once that was complete the fighting over their former space started to morph in to an EU flag, and the intersection of France and Germany became the EU.

I think also briefly Italy had the south side and Spain had the East, but those went back to France/Germany respectively.

</comment><comment><USER29> Cool experiment, very disappointing outcome. To me it was an experiment in dynamic, ever-changing art; giving way to creation and destruction. In the end, it was just scripted bots working to _preserve_ art, mostly corporate logos and national flags. Why was there no captcha?!

<comment><USER14> Interesting philosophical contrast between this, your suggestion, and [http://www.milliondollarhomepage.com](http://www.milliondollarhomepage.com) \- anarchy vs benevolent dictatorship vs capitalism.

<comment><USER17> The benevolent dictatorship being represented by any pixel rendered image you find to be "benevolent" presumably.

Compare the r/places output to MDH and [http://media.cntraveler.com/photos/56d0aee058d9a8773c109eb2/...](http://media.cntraveler.com/photos/56d0aee058d9a8773c109eb2/master/w_775,c_limit/virgin- gorda-the-baths-cr-getty.jpg) and you'll probably establish a consensus for the "benevolent dictator" made art above the others?

</comment></comment></comment><comment><USER30> I find this interesting in what it lacked:

* No Google / Twitter / Facebook / Amazon

* No news networks (except NPR)

* Hardly any corporations except for Tesla, Space X, AMD, Lego and IKEA

* No GTA, FIFA, large corporate games

* Only 6 actual people (1/3 of which was the Dutch dutchy)

* No films

* No iconic logos - e.g. Olympics rings, Nike, McDonalds

<comment><USER31> Lego and IKEA were only there because they represented the rivalry between Denmark and Sweden. But I do find it interesting how Tesla and Space X fans are so dedicated that they'd be willing to fight for them.

<comment><USER30> > so dedicated that they'd be willing to fight for them

Now that's brand loyalty.

I'm imagining the Great World Brand War of 2130 and the aftermath with McDonalds youth movement being convicted of the genocide of the Nike sneakers resellers

</comment></comment></comment><comment><USER32> It was neat how we at /r/archlinux were able to eventually come to an agreement with /r/sweden not to deface each other's logo, so that we had one less border to worry about :-)

Thanks /r/sweden!

</comment><comment><USER33> My favorite subreddit (r/2007scape) went head-to-head against r/The_donald for the top left corner. Right now it's "connection lost - please wait, attempting to reestablish" but apparently the_Donald wanted to make it an American flag, and things got pretty heated.

We won :)

<comment><USER3> I didn't know about the competition against /r/t_d, but the sheer amount of threads on Sunday in /r/2007scape about defending and call to arms is what was beginning to aggravate me. I think there were 5 actual posts about the game or discussions on their front page, and 20 about /r/Place.

<comment><USER33> Yea they really wanted to win. Honestly it was pretty frustrating because I rely on them for 87% of my meme consumption, but I'm glad that we won a "place" on /r/place

</comment></comment></comment><comment><USER34> Reminds me of [http://artcontext.net/act/06/glyphiti/docs/index.php](http://artcontext.net/act/06/glyphiti/docs/index.php) a black and white multiplayer canvas that has been running since 2001.

They also animate the progress here: [http://artcontext.net/act/01/glyphiti/anim/](http://artcontext.net/act/01/glyphiti/anim/)

</comment><comment><USER30> Did anyone note the similarity to playing Go / Weiqi?

Watching [0] the blue corner expanded masssively and then getting eaten from within somehow reminds me of all of the complexities of playing go when someone can place stones anywhere in your territory.

[0]: [https://www.youtube.com/watch?v=XnRCZK3KjUY](https://www.youtube.com/watch?v=XnRCZK3KjUY)

</comment><comment><USER35> >Did Reddit's April Fool's gag solve the issue of online hate speech?

I certainly hope that doesn't become a widely accepted solution; To me (I didn't participate but have read about the event) it seems like their solution was to

A) marginalize each individual's impact/voice

B) moderate heavily to remove offensive things

This doesn't just remove "hate-speech", this removes anything unpopular.

</comment><comment><USER36> It continues to inspire creativity even after it closed: [https://www.reddit.com/r/videos/comments/63amnd/rplace_heatm...](https://www.reddit.com/r/videos/comments/63amnd/rplace_heatmap_made_into_a_show_opening/)

</comment><comment><USER37> The Button and Robin were awesome but this was on another level. I loved hanging out in the different factions' Discord servers and observe troops being rallied and defenses coordinated. It was an amazing 72 hours and I wonder how Reddit will top this next year.

I was also really impressed with how little obscenity there was. I fully expected it to be overrun by trolls. In retrospect I agree with the article that the technical limitation for creating was a contributing factor. If you want to see what happens when no such limitation exists and trolls get the upperhand, check out the timelapse of my own multiplayer drawing site:

[https://youtu.be/qIJ3XFPRsSw](https://youtu.be/qIJ3XFPRsSw)

</comment><comment><USER38> > _16-bit palette_

Did they mean 16 color palette?

<comment><USER38> Answering to myself:

They almost certainly did. There's only 16 colors in the final image:

      $ curl -s https://i.redd.it/wc436nf7fdpy.png | pngtopnm | ppmhist
      libpng warning: iCCP: known incorrect sRGB profile
         r     g     b         lum     count
       ----- ----- -----      -----   </comment></comment><comment>-
          34    34    34         34    258550
         255   255   255        255    154487
         229     0     0         68    123218
           0     0   234         27     90720
         229   217     0        196     63755
         229   149     0        156     55643
           2   190     1        112     40918
           0   131   199        100     32930
           0   211   221        149     29820
         255   167   209        198     28576
         228   228   228        228     27733
         136   136   136        136     26035
         130     0   128         54     20019
         160   106    66        118     18023
         148   224    68        183     16047
         207   110   228        153     13526

</comment><comment><USER39> Reminds me of a more dynamic version of the Million Dollar Homepage from many years ago. [http://www.milliondollarhomepage.com/](http://www.milliondollarhomepage.com/)

</comment><comment><USER40> I'm surprised that the article doesn't talk about how things were ruined towards the end with bots mindlessly overwriting squares to impose a pattern on the grid instead of collaborating.

</comment><comment><USER41> This collaboration reminds me of Wikipedia, where users work together to create articles and remove vandalism.

</comment><comment><USER22> Here's a timelapse of the entire event: [https://www.youtube.com/watch?v=XnRCZK3KjUY](https://www.youtube.com/watch?v=XnRCZK3KjUY)

I found this whole thing to be incredibly fascinating. It's pretty amazing to see how everyone just sort of spontaneously banded together to create little works of art on the board which they could never have made on their own. Everytime I watch the timelapse I notice something new.

It's also interesting to note that because the impact of any individual user on the board was pretty limited (you could only place one pixel every 5 minutes, and even then there was no guarantee the first pixel you placed wouldn't be overwritten by someone else before you were even allowed to place another), every significant piece of artwork on there had tens or even hundreds of people involved in creating and maintaining it.

In addition to the various artworks on the board, there were also several major factions scattered throughout the board with their own goals. /r/TheBlueCorner dedicated themselves to filling the empty space in the bottom right corner of the board with blue pixels, while /r/theblackvoid formed to erase various artworks by replacing them with black tiles. If you pay attention you may also notice several other factions in the timelapse (the Rainbow Road, Draw Hearts, Erase the Place, and The Green Lattice were a few other notable ones).

Other interesting events to note include [the German invasion of France]([https://www.youtube.com/watch?v=ParHJmq2aCs](https://www.youtube.com/watch?v=ParHJmq2aCs)) (and resulting peaceful resolution), [The Void's (unsuccessful) attack on the OSU logo]([https://i.imgur.com/Tpmvrcc.gif](https://i.imgur.com/Tpmvrcc.gif)), and [several factions ganging up to attack the US flag]([https://gfycat.com/InfamousShyEeve](https://gfycat.com/InfamousShyEeve)) while most of the US population was asleep. There's plenty of other stuff you might notice too if you look hard enough. (For example, can you find Waldo?)

[Here's what the canvas looked like when the event finally ended]([https://i.imgur.com/ajWiAYi.png](https://i.imgur.com/ajWiAYi.png)). Other interesting stuff to note include [this animated heatmap]([https://i.imgur.com/a95XXDz.gifv](https://i.imgur.com/a95XXDz.gifv)) by /u/jampekka of activity on the canvas, and [this graphic]([https://i.imgur.com/SEHaUSJ.png](https://i.imgur.com/SEHaUSJ.png)) by /u/alternateme highlighting all the white pixels which never got touched throughout the experiment.

</comment><comment><USER42> Wow, this is just fascinating. I don't really know Reddit, so this is the first time I heard of r/place. It reminds me of a couple of earlier experiments in emergent social organisation. Loren Carpenter's 1991 Pong, which is documented in Kevin Kelley's book Out of Control[1]. Also, DARPA's 2009 Network Challenge[2] (weather balloons)

[1] [http://kk.org/mt-files/books-mt/ooc-mf.pdf](http://kk.org/mt-files/books- mt/ooc-mf.pdf) (page 11)

[2] [https://en.wikipedia.org/wiki/DARPA_Network_Challenge](https://en.wikipedia.org/wiki/DARPA_Network_Challenge)

If Reddit releases the pixel placement timings and researchers can go back over the boards to investigate communication about r/place, I believe this should be a very rich trove of data for sociologists.

</comment><comment><USER43> Are there any open-source projects out there which can do this?

The resulting 10 minute time-lapse video is an absolute thing of beauty. [https://www.youtube.com/watch?v=RCAsY8kjE3w](https://www.youtube.com/watch?v=RCAsY8kjE3w)

I once ran a site years ago where people could doodle these little squares. It didn't take long for 'wars' to break out, involving various insignia. And cartoon genitals.

It got to about 500k before something went horribly wrong with a hard disk on the server. :(

</comment><comment><USER44> I made a very similar site a few years ago, except you can't overwrite other peoples work: [http://paint.reednj.com](http://paint.reednj.com)

(Its not moderated, so probably NSFW)

</comment><comment><USER45> They should make a jigsaw puzzle of this. It would be entertaining.

<comment><USER22> Here's the Reddit thread about that: [https://www.reddit.com/r/place/comments/639mwv/i_just_had_th...](https://www.reddit.com/r/place/comments/639mwv/i_just_had_the_best_idea_ever/)

<comment><USER45> Haha. Of course someone else has thought of this too. I think it would be fairly entertaining.

</comment></comment></comment><comment><USER46> Not a fan of the 3D chart they used - lots of data gets hidden by towering spires, and the camera tilt adds its own bit of distortion.

Did anyone create an old fashioned 2D heatmap?

<comment><USER47> Yep [0]. They also made a cool TV show intro [1] out of it.

[0]:[https://www.reddit.com/r/place/comments/63240q/rplace_activi...](https://www.reddit.com/r/place/comments/63240q/rplace_activity_animated_heatmap/)

[1]:[https://www.reddit.com/r/videos/comments/63amnd/rplace_heatm...](https://www.reddit.com/r/videos/comments/63amnd/rplace_heatmap_made_into_a_show_opening/)

</comment></comment><comment><USER48> france tried to invade bitcoin but r/bitcoin fought them off after much struggle lol

very interesting social experiment!

</comment><comment><USER49> Ah, the ample parallels you could draw with this and freedom.

<comment><USER50> Please expand?</comment></comment>


Best ESP\Email Provider for lead outreach? - <AUTHOR> Struggling to find a quality provider who allows emailing prospects. What are most people using? <comment><USER2> "Struggling to find a quality provider who allows emailing prospects"

Do you perhaps mean spam?

<comment><AUTHOR> No, cold out reach to targeted audience.

<comment><USER2> AKA spam.</comment></comment></comment>


Thorkil Sonne: Recruit Autistics - <AUTHOR> http://www.wired.com/techbiz/people/magazine/17-10/ff_smartlist_sonne

<comment><USER2> One of my pet peeves is articles that idolize autism like this. Most people with autism are severely developmentally delayed. Autistic savants that you often hear about in the media are extremely rare.

"As a general view, they have excellent memory and strong attention to detail. They are persistent and good at following structures and routines."

Bullshit. Anyone who actually works with autistic people would cringe at that line.

It's like making an unqualified statement "amputees are the best runners" because a small handful use those awesome prosthetics to run super fast.

<comment><USER3> Well obviously he's not hiring people at the extreme end of the autism spectrum - and he has actual data to back up his statements so I don't see why you should criticize him by taking one or two statements out of context like that.

<comment><USER2> I didn't take it out of context. The entire article puts autism on a pedestal.

</comment></comment></comment><comment><USER4> "As a general view, they have excellent memory and strong attention to detail. They are persistent and good at following structures and routines," he says. In other words, they're born software engineers."

Wrong, completely totally backwards!

Good software engineers need to be good at communicating. They need to be good writers. It also helps if they have terrible memories, because if they forget easily then they are forced to write code thats easy for them to follow and understand days or years later, and consequently the same for the rest of us working with them.

<comment><USER5> This also made me cringe. The thing that drove me to programming is how much I _hate_ routine. All these traits are strengths of computers which we then program so we don't have to do those repetitive things ourselves. I suppose to the laymen writers at Wired us software engineers are just extensions of the computers we are seated at.

<comment><USER6> They don't write software, they test it.

They type in endless amounts of test data, and manually test all sorts of applications.

</comment></comment></comment><comment><USER7> There are some people who would send your typical HR bunny screaming from the interview in panic, yet would perform very well if you could just lock them in a room and push food and energy drinks under the door. Take my father-in-law (please!!), the Asperger's poster child. Here's a guy who can fix any kind of mechanical or electrical device (making his own parts and tools if necessary) and can explain in horrifically painful detail how just about everything in the universe works, but talks and talks and talks (mostly about himself) from the moment he wakes up till the moment he falls asleep. A great guy in many ways. A genius even. But a complete failure (and a real nuisance) in social interactions. In the right setting he'd be a high value employee, in the wrong setting he could destroy an organization.

</comment><comment><USER3> I'd love to work in an environment where my personality (or lack thereof :p ) is not seen as problem that needs fixing. Currently I'm forced to work in an open-plan environment with no privacy, no noise barriers, nothing stopping random people from interrupting me. It's a disaster for me. I need a quiet space free from people looking over my shoulder and I can do amazing things. Instead I get lectured on punctuality and 'teamwork' by our MD. Rage.</comment>


7 Interesting HN Startup Month Apps - <AUTHOR> http://www.minklinks.com/weblog/2010/11/14/7-interesting-hn-startup-month-apps/ <comment><AUTHOR> I thought I'd write about some of the apps that are coming out this november (as there's now over 30 of them). What does HN think? Are there any of the apps on startupmonth that sound interesting to you?</comment>


Consuming Web APIs with Groovy - <AUTHOR> http://www.getspun.com/consuming-web-apis-with-groovy/

<comment><USER2> > We use Groovy a lot at SPUN and we love it. Our CMS is written in grails and > our feed consumption "sponge" is Groovy + Jetty and GPars with a frontend > written in KnockoutJS. What I like most about groovy is that it builds on > the existing Java ecosystem and, being so close to Java, new developers can > learn it in no time. Once you get into the new features that Groovy brings > to the table it really makes coding a lot more fun, but you can learn those > features over time while still being productive with your existing Java > chops.

What new features are these? Static compilation is hardly production ready, as seen by this bug in Groovy 2.1.0 reported only last week... [http://stackoverflow.com/questions/14774709/groovy-2-1-0-wei...](http://stackoverflow.com/questions/14774709/groovy-2-1-0-weird- behaviour-of-switch-case-break-statement-with-compilestatic)

Groovy's static compilation came with Groovy 2.0. Although officially released in June 2012, it _really wasn't released for production use until it was bundled as part of Grails_ 2.2 in Dec 2012. The 6 months from June to December was unofficially _just more beta-testing_ with a larger base of users, those who download standalone releases of Groovy. Grails, however, doesn't use any of the static compilation features in Groovy 2.0. All the testing of Groovy 2.0 was just to make sure the inclusion of static compilation in Groovy _didn't break any of its dynamic compilation use in Grails_.

Maybe the new feature in Groovy 2 you're talking about is invoke-dynamic. In both Groovy 2.0 and 2.1, the code using invoke-dynamic is bundled in a separate jar-file which only runs on Java 7. Grails and Gradle don't bundle this other invoke-dynamic jar file, and don't intend to for Grails 2.3 and Groovy 2.1 either. Whereas the legacy stream of Groovy can be tested to see that the static compilation doesn't break the preexisting dynamic compilation, the invoke-dynamic jar needs far more testing because it would actually replace the existing dynamic-compilation codebase, so Grails and Gradle won't bundle it.

You're just a patsy of the Groovy/Grails project management pitching for Groovy 2.1 beta-testers for Grails 2.3 when you write in your blog: "Once you get into the new features that Groovy brings to the table it really makes coding a lot more fun, but you can learn those features over time while still being productive with your existing Java chops."

If you really want static compilation, use Scala which has been battle-tested far longer than Groovy's. If you really want invoke dynamic, use JRuby which bundled it even _before_ Java 7 was released. Groovy is really only useful if you use Grails, and for quick testing scripts - quick to write but slow to run, that is.

<comment><AUTHOR> When I said "new features" I meant the core language features of groovy (closures, etc.) not static compilation. If speed is really that important to you, sure scala is faster today, but groovy will catch up very soon.

<comment><USER2> > If speed is really that important to you, sure scala is faster today, but > groovy will catch up very soon.

I didn't mention anything about speed. I talked about being _free of bugs_. Scala is more stable than Groovy' static compilation, having been battle- tested for much longer. I doubt Groovy's static mode will ever be more reliable than Scala.</comment></comment></comment>


Ask HN: My internship is asking me to not apply elsewhere, how do I say no? - <AUTHOR> Right now I have a fun internship with a small startup that works on a contract-by-contract basis. It pays really well ($22/hr + bonuses) and I have great relations with my boss & manager.
The problem is that the job is not enough to go full time on, there are often a couple off-months between contracts and we can only afford 20hr work weeks. I've started applying elsewhere in the city in hopes of getting an internship that can transition to a full time job outside of college (i'm in my last year).
My boss just emailed me today that they may have a contract secured by the end of Q1, and asked me if I could not apply anywhere else and would value my commitment to the summer. How do I tell him I am applying elsewhere without burning a bridge?
Thanks for any help guys <comment><USER2> I will give you an advice (12 years industry experience) which hopefully you should remember forever:

No one is looking out for you except YOU. PERIOD.

Don't forget this rule above. If your boss decides that they don't want/need to hire you at the end anyway, you are screwed.

Tell your boss "I look forward to working with you if it happens" and then keep applying wherever you need to apply. Your boss may mean well but at the end of the day, he has to report to someone and he has to look out for himself/herself.

Never ever put your career in anyone else's hands except yours.

<comment><USER3> Solid advice. Having more options is always better. Companies are not your friends. They don't deserve loyalty.

</comment></comment><comment><USER4> If you have to reply to the e-mail to acknowledge it, just say something along the lines of "Sounds great, thanks for letting me know!"

You don't have to say you're applying elsewhere. Him asking you not to apply elsewhere, is not the same as him demanding you to tell him if you are doing so.

Business deals fall through all the time, I wouldn't put all my eggs in one basket. A contract is not a contract until it's signed. Even if they sign it, there's no guarantee that they will keep you on.

A minor issue, but something still to note: Your boss said the contract "may" be secured, not that it "will" be secured.

<comment><USER5> I'd be a little careful here.

Boss said he would "value your commitment" for the summer span. By replying and saying anything in the affirmative, will the company consider this an informal agreement in lieu of the (upcoming) written contract?

tldr: if you reply yes, will they take it as a verbal contract?

I wouldn't say anything yes or no, perhaps something along the lines of "when a contract is ready to be presented to me in writing, I'd be happy to review it." And nothing else.

<comment><USER4> I don't think a reasonable business person would see that hypothetical e-mail exchange as something to count on. I think the boss is just trying to guarantee he/she will have a good worker if the deal happens. An emotionally- invested person might consider the e-mail as an agreement, but such person shouldn't expect a worker to sacrifice his/her future opportunities for a risk like this.

<comment><USER6> Looks like they are budgeting / sending an offer and having a $22/hr labor cost is an advantage.

Dont' tell them lies unless you have to. Just say thanks for counting with me or something similar; but _keep_ looking just because, shit might happen and you'll need to put food on the table anyway.

</comment></comment></comment></comment><comment><USER7> As it concerns "burning a bridge", remember that your employer is the one soaking it in gasoline from multiple five gallon containers, they're just asking that you not strike a match.

Which, of course, is completely unreasonable. Even if you have a written piece of paper with signatures on it, if they decide they don't need you anymore or can get another intern for less, they will effectively tear that piece of paper up and send you your way.

Moral: as others have already said, keep applying and let the cards fall as they might. Unless they have a full-time offer in hand for you _today_ , you have no obligation to them. And I can guaran-damn-tee you that they feel absolutely no obligation to _you_. I mean, read your 2nd-to-last sentence: do you sense any commitment or obligation on the part of your employer? No, the commitment is completely one-sided.

</comment><comment><USER8> So in other words, he's dangling a carrot that's about two months away?

BTW, if you're dealing with "contracts" (implying a consultant/independent contractor relationship), then he's not your boss, he's your client. That's a big difference.

The main thing here is that he's asking you to commit to something that he's not willing to commit to himself. To me, a measured, non-commital response would be in order. Keep it polite and let him know that you'd be happy to discuss a contract for the summer once he's able to commit to one.

No point in aggravating the client but this is a business deal (selling your time and expertise). Treat it as such.

</comment><comment><USER9> An employer cannot tell you to not apply for other work.

Just respond saying something like: "Thank you for the heads up. I look forward to it."

Nobody looks out for you in this life except you! (within reason...). An employer has to look out for the company first.

<comment><USER10> >An employer cannot tell you to not apply for other work.

In the US, uh of course they can.

Is it legal? Most people don't know. Will you sue over it? Unlikely as it's probably not worth the hassle.

People can do/say pretty much anything and the vast majority of the time the consequences are minimal or nonexistent.

<comment><USER9> I'm not saying they _won 't_ ask. I am saying they _cannot_ ask. You are right, however. There are minimal to no consequences if the employee doesn't press the issue. If the employee did, I am not sure it would really go much further without significant resources to sue.

<comment><USER10> > I am saying they cannot ask

Based on what exactly? I'm not familiar with any specific law prohibiting it.

<comment><USER11> They can _ask_ for anything. If you say yes, though, the only thing binding you is your own sense of obligation to keep your word. The promise to not look elsewhere is not legally enforceable (at least in many states; IANAL and I don't know whether it is not enforceable in all states).

</comment></comment></comment></comment></comment><comment><USER12> A lot of events can happen between now and then - they have made no hard promises (and to their credit they seem to have been truthful about why), but if they don't get a contract secured, then you're out of a job and delayed in a search for for a new one. That describes a path where one set of outcomes that can basically delay your life progress.

It seems you don't have any hard stake in the startup, you have a soft stake in the work relationship there - but I would suggest that if that relationship doesn't stretch to accommodate the risks of both sides than it really wasn't that much of a relationship to start with.

You can be as kind as possible and say you're not looking specifically to leave, but that you feel you have to keep your options as open as possible too, and I think that is perfectly fair on your part.

</comment><comment><USER13> Draw up a contract that sells your option to apply elsewhere for what you decide the value of that option is. See if they want to buy.

<comment><USER14> This would be amusing, but is basically how a retainer works.

<comment> wes-k Right and this is the exact use case for retainers! We want to reserve you for possible future work and you want to not be broke while waiting for work.

</comment></comment></comment><comment><USER15> Welcome to the post-college real world :)

Honestly, there isn't enough info in your post for anyone here to give a proper answer. eg the city you are in makes a difference. No worries, some general things to think about in your last year of college:

1\. Don't work for a bad boss if you can avoid it.

2\. Figure out what a bad boss means to you. But my criteria (especially right out of school) includes working for a boss I can learn from and a boss with high EQ (a boss who understands when his/her employees are stressed or exhausted or confused it makes a big difference).

3\. Learning how to not burn a bridge is smart. But burning them happens sometimes. Try to please everyone and you will lose. It gets easier with experience (plus if someone is talented at their job, these ppl seem to be able to not burn bridges no matter how big an asshole they are). Maybe one reply to your boss could be: 'Thank you. Please let me know when you get that contract so I can discontinue my current talks with other companies'.

4\. Believe in your startup and its product. Maybe more important than a good boss, ymmv.

5\. Always be networking and getting to know people in your industry/in your city. Even if you don't call it "applying" I would be reaching out to other startups now. Email them say you are graduating and ask to learn more about what they do.

</comment><comment><USER16> You be honest and forthright: tell them the reasons for your concerns, and that ultimately you have to do what you think is right for your current situation.

If that "burns a bridge" then they're not very reasonable. They might not be _happy_ about it, but that's a separate issue.

</comment><comment><USER17> It sounds like you will not be able to go full time after your graduate due to them not having enough hours. I doubt they would want to pay you a non- internship rate and once you grad, they'll replace you with another intern. Another red flag to me is them asking you to not look for another job. Sounds like they are more concerned with themselves than with your well being. As others have said, just say thanks for letting me know, etc.

Apply elsewhere. Sounds like a fishy environment to work in to me.

</comment><comment><USER18> Just say yes you won't apply elsewhere and then apply elsewhere anyways. How are they going to know? Besides they can't enforce a contract like that in court because 1. there's no consideration 2. it's a contract in restraint of trade. So just lie.

<comment><USER11> IMHO, that's bad advice (see other comments about not burning bridges).

</comment></comment><comment><USER11> [http://www.schlockmercenary.com/2017-01-26](http://www.schlockmercenary.com/2017-01-26)

I don't know if you actually want to use this phrase...

But to me, it's like this: If they _guarantee, in writing, in a contract that gives you recourse if they fail to perform_ , that they will hire you, then it's reasonable for them to ask you to give them, in an enforceable contract, your promise that you won't look elsewhere. If they're _not_ giving you that kind of guarantee, your answer should be "no", however politely worded.

</comment><comment><USER19> In dollar terms, how much does your boss value your commitment?

What if you want to explore a different area of technology? It would be very unreasonable to not talk to other companies and limit yourself to the same tech.

Why are you limiting yourself to one city?

<comment><AUTHOR> I really like the city i'm in, and want to stay here a couple more years is all.

My boss has expressed that if funding was available, I would be salaried and offered a full time position. The issue is that the company _may_ never get that much funding, it's all dependent on how successful they are at selling the product.

<comment><USER20> "My boss has expressed that if funding was available, I would be salaried and offered a full time position"

In writing?

"The issue is that the company may never get that much funding"

Which means that you MAY be out of a job, and you didnt apply elsewhere. You have savings? It sounds like they know that you MAY be out of a job, and are asking you to not have other options. You MAY not like that.

"it's all dependent on how successful they are at selling the product"

Something like 9/10 startups fail...

Additionally, remember that random people on the internet are not lawyers. I have only taken 1 semester of law in college, and even I hear some ridiculous things people think are true. If you cant afford a lawyer, then you cant afford to be out of a job.

</comment></comment></comment><comment><USER21> "I'm crossing my fingers that I'll be able to work with you this summer but in the meantime I have this whole "eating and living indoors" habit to support."

And BTW if you are a developer in the US, $22hr is easily 1/2 what a real job would pay. Companies tend to not give a raise to market rate if they get you "cheap" initially. Absolutely do shop around and find your market value. I think you might see why they'd love to keep you on after you graduate.

<comment><USER22> I'd add that there are a lot of shops that run on cheap intern labor. One of the tells is if nobody ever transitions from intern to full time work.

</comment></comment><comment><USER23> Are you an employee (W-2) or contractor (1099)? In the latter case there is an expectation that you have multiple "clients". In either case, if this happened to me I would talk (as in, in your next 1:1 meeting or phone call), not by email, to communicate that at this point I need to keep my options open but if that ends up happening then it sounds great -- and also my hourly rate at that point will change to $(22 + X).

</comment><comment><USER24> A bit off-topic, but why are you calling it an internship? It sounds more like a part-time job.

</comment><comment><USER25> 1) It is illegal for them to ask as some have surely pointed out already. 2)$22 is shit pay. Junior devs in NYC make 50. 3)These people are exploiting you and unless you have kids to feed, you should quit immediately.

<comment><USER10> >It is illegal for them to ask as some have surely pointed out already.

Just curious, what law does this break?

</comment></comment><comment><USER26> Your boss:

"Hey! We're giving you a bad employment deal, so don't talk to anyone else, so you don't figure it iut"

</comment><comment><USER27> don't say anything, just apply elsewhere</comment>


An interesting Amazon Linux memory bug - <AUTHOR> https://whatshouldyoueat.com/2019/05/13/linux-dentries/ <comment><USER2> Any idea which version of CentOS this was encountered on?

<comment><AUTHOR> Just checked and the instances are running Amazon Linux AMI 2018.03, which has `ID_LIKE="rhel fedora"`.

EDIT: I changed the title of this post to reflect that fact.

<comment><USER2> Awesome, thanks</comment></comment></comment>


Attention Is the Real Resource - <AUTHOR> http://daringfireball.net/2010/03/attention_is_the_real_resource <comment><USER2> solution: design the rss feed with "top readers" in mind, inject "calls to action" links in the rss feed (like "Hey you, yea you the RSS subscriber, you're an avid reader and I appreciate that! I give FULL CONTENT access via RSS in hopes that my most engaged readers will add valuable input to my posts. Click here to comment and I'll try to respond and maybe even attach our discussion to the article. (at least click through to see what others readers are saying!)"

Get creative! Engage! Raise your expectation of engagement for your most valuable readers. If a blogger is doing things right he/she will have designed his blog posts to be a valuable "conversation" (and therefore making rss feeds merely an "entry point").

</comment><comment><USER3> Something Gruber didn't go into is how well Snell's comparison between web and rss tracks to earlier comparisons made between print and web.</comment>


The Power of Serverless - <AUTHOR> https://elazizi.com/the-power-of-serverless-part-1 <comment><USER2> Blank page in Chome with uBlock</comment>


Microsoft REST API Guidelines - <AUTHOR> https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md <comment><USER2> Pagination is one of those things I feel like so many of these things get wrong. LIMIT/OFFSET (or as MS likes to call it, TOP/SEEK) style results in O(n²) operations; an automated tool trying to pull the entirety of a large collection in such a scenario is not good. I have to again recommend the excellent "Pagination done the Right Way" presentation[1] from Use the Index, Luke (an equally excellent site).

Just return a link to the "next page" (make the next page opaque); while this removes the ability to of the client to go to an arbitrary page on its own, in practice, I've never seen that matter, and the generalized URL format allows you to seek instead of by LIMIT/OFFSET by something indexable by the DB; HTTP even includes a standardized header for just this purpose[2].

I also think the generalized URL is more in line with Fielding's definition of REST, in that the response links to another resource. (I don't know if being in the header invalidates this; to me, it does not.)

If you get the metadata out of the data section of your response, and move it to the headers, where it belongs, this usually then lets you keep the "collection" of items you are return as an array (because if you need to put metadata along side it, you need:

      {
         "the_data_you_really_want": [1, 2, 3],
         "metadata, e.g., pagination": {}
      }

vs.

      ["the", "data", "you", "wanted", "in a sensible format"]

)

(I've seen metadata-pushed-into-the-body turn API endpoints that literally need to return no more than "true" or "false" into object that then force a client to know and look up the correct key in an object… _sigh_.)

[1]: [http://use-the-index-luke.com/no-offset](http://use-the-index- luke.com/no-offset)

[2]: [https://tools.ietf.org/html/rfc5988](https://tools.ietf.org/html/rfc5988)

<comment><USER3> Returning just an array from a json-endpoint that may contain sensitive data is a vulnerability: [http://haacked.com/archive/2008/11/20/anatomy-of-a- subtle-js...](http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-json- vulnerability.aspx/)

(edit: may be mitigated in newer browsers)

<comment><USER4> The obvious mitigation is don't visit untrusted endpoints from your API client, and/or don't run a script interpreter inside your API client.

<comment><USER3> That's not what the vulnerability is here. If you have a server endpoint that returns an array without wrapping it as a property on an object then an attacker can write a webpage that overrides the Array prototype and requests the json from your page as a script, thereby bypassing the cross origin check it would be subject to as an xhr request. So if you have a page which returns sensitive information as an array you (were, it seems browsers probably don't allow you to override the array prototype anymore) are vulnerable to the attacker stealing a signed in users secrets.

<comment><USER4> On the contrary, that's precisely the vulnerability:

1\. The API server needs authentication, which gets cached in the user-agent.

2\. The same user-agent, with the same authentication context, is then directed to a malicious site.

3\. The user-agent contains a javascript interpreter, and the malicious website serves a script to override the Array prototype.

4\. The same script then executes a CSRF request to the API server, reusing the cached authentication context, and therefore stealing the response.

A browser fits all the necessary conditions that must exist for this vulnerability to be exploited, but if you're the consumer of the API, you don't have to use a browser as your user-agent. You can write your own, which you'd do if you're making these requests programmatically in a non-web application.

Regardless as to which user-agent you use, a viable mitigation is to not visit untrusted endpoints with the same cookie jar or authentication context.

Another viable mitigation is to omit including a script interpreter in your custom API client. This is in fact usually the case.

<comment><USER3> Sorry, you are right.

</comment></comment></comment></comment></comment></comment><comment><USER5> Funny that Microsoft uses OData as an example of a bad URL:

[https://github.com/Microsoft/api- guidelines/blob/master/Guid...](https://github.com/Microsoft/api- guidelines/blob/master/Guidelines.md#71-url-structure)

Whilst continuing to praise OData as "the best way to REST" \- [http://www.odata.org](http://www.odata.org)

<comment><USER6> Microsoft came up with OData about 10 years ago, but it's now steered by a technical committee with a lot of participants. I wouldn't necessarily be so quick to assume that the OASIS committee - or Microsoft's representatives on it - speak for all of Microsoft. Let alone an internal guidelines committee that they apparently convened fairly recently (given the age of the report) when they use that slogan.

<comment><USER5> This isn't just some poorly labelled content from a 10 year old legacy website from a time before they knew any better, the OData website got a recent redesign sporting new Stock photos and even larger font for their disingenuous labeling which still continue to push OData crapware under the REST banner to fool devs/CIO's into thinking if they adopt OData they're taking advantage of the best form of REST - which is in-contrast and devalues sincere efforts like this where they're actually looking to promote good HTTP API practices.

<comment><USER7> I recently had the misfortune to have to tackle oData to talk to Dynamics CRM. The choice was between that and SOAP so it was the lesser of two evils.

But compared to the other nice, modern REST API's I'm used it smelt of mould and enterprisey cobwebs. I'd have preferred an old school RPC API over that. At least API's that abuse REST from that direction tend to have the virtue of simplicity.

<comment><USER8> For that matter, I know it's "bad" to use RPC, but imho it's sometimes the cleanest/simplest interface you can make for something on an API.

<comment><USER9> There's nothing wrong with RPC APIs. Other than being "Not Cool" due to the legacy of SOAP, they can deliver some very nice value.

Various RPC mechanisms like Bond and Protocol Buffers (and more recently GRPC) are trying hard to make RPC cool again. Personally, I hope they succeed, as REST (like any technology) doesn't work for everything.

<comment><USER8> For that matter, communication abstractions over websockets... Which has been most interesting to me in terms of offering some better security choices.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I'd love to see some guidance on how you're supposed to do file uploads (think: uploading an image avatar for a user) and fit it into the REST structure. These guidelines don't even mention "x-www-form-urlencoded" except in a bit of fluff about CORS.

Made more frustrating by Microsoft's own WebAPI2 basically having zero support for file uploads, meaning we had to go way outside the library to code support for it.

Not sure why that's such a blind spot. Doesn't _every_ web service need to upload files eventually?

<comment><USER11> POST /users/{id}/avatar

?

What additional guidance would you expect?

<comment><USER12> You can turn the uploaded image into base64 string in the client and then just post it as part of your JSON payload.

<comment><USER13> This is what I've been doing and it's very simple for both client apps and on the server. I don't know if this is feasible for larger files tho.

</comment></comment></comment></comment><comment><USER14> Well presented. It would be great if there was a language / framework that made this guaranteed. As-is everything just returns 500 error on any exception, lets you return errors with 200, allows update on GET, etc. Even the Haskell ones.

<comment><USER15> Handling errors over REST API is something I've struggled with. What's the best way to handle errors? Data validation errors will be different from system/server errors. Tough to establish a universally applicable error response structure.

I used to be in favor of sending 200 responses with error codes but now gravitating back towards relaying the most relevant HTTP error & letting the clients handle it.

<comment><USER16> Any app of decent size will probably end up passing HTTP's error codes. 200 + error is OK, except it can mess with caching. A 5xx with details in the response is fine.

You might be tempted to map some errors, like "item not found" to 404, and so on. But you still need to provide the real error code. So you're not gaining much.

Honestly, I don't get the obsession with using HTTP features to represent part of an API. It never saves work; you're writing a custom client each time anyways. From a purely code perspective, you're going to deserialize the body or a context object from a header. Moving that data into multiple headers can only require more code, not less. Same for verbs. I've _never_ gotten any benefit beyond GET-for-read, POST-for-write.

Elasticsearch is a good example. The URL space is overloaded with special things, allows you to create objects you can't reference, and so on. They use verbs, except you still have extra parameters tacked on. There's zero benefit to me, the user, of them making it REST like.

Maybe if REST-someone creates a machine usable spec like WSDL (just "simpler") then all these HTTP headers could be put to use.

<comment><USER17> The advantage is that there is some level of standardization.

404? That means the entity doesn't exist. 302? I should look somewhere else. 401? The server doesn't know who I am.

Accept? I can specify the format. ETag? I can get a faster response if I include the token in the next request.

This stuff is really, really common, and people can learn your API very quickly. A transparent caching server can improve performance.

Sure, with a custom protocol you can get a tight system. Hell, write your own transport layer for even more control. But it will take longer to learn and harder to interoperate.

<comment><USER16> The time spent reading that 404 in this case means "the object ID isn't found" versus "this path doesn't exist" pretty much negates any benefit - you still have to include sub codes. Same for "access denied because token expired" vs "invalid token". Not mention all the stuff that'll get crammed into 400/500/503.

If your app is simple enough that _all_ errors map 1:1 to HTTP, great. Or if it doesn't need that level of error management. Otherwise HTTP just confuses the issue.

<comment><USER17> So, you just want to explain the error further? Wonderful. RFC2616

> the server SHOULD include an entity containing an explanation of the error > situation

\---

The 3-digit status code tells consumers (1) the status category (success, redirect, client error, server error) and (2) a more specific status within that category. It does that in a way that doesn't require me turning to your API docs every 3 seconds.

</comment></comment></comment></comment></comment></comment><comment><USER18> Zalando released our RESTful API guidelines a few months back -- they're very comprehensive and open-source. Feedback and suggestions welcome: [https://zalando.github.io/restful-api- guidelines/](https://zalando.github.io/restful-api-guidelines/)

</comment><comment><USER19> It's great to see Microsoft release these guidelines. It's good work, a broad document with a lot of interesting topics covered. You can always debate the details (the pagination discussion here is very interesting), but having seen first hand at Zalando how much dedication and effort goes into API guidelines to support a large number of service teams, plus releasing them into the public, it's no small feat and they deserve credit for doing this.

There's naturally been some discussion around REST/HTTP APIs and design styles. One of the things we've tried to do with the Zalando guidelines ([https://zalando.github.io/restful-api- guidelines](https://zalando.github.io/restful-api-guidelines)) is go into more detail on using HTTP and JSON, and how REST properties are used. Zalando, like everyone else, has had to think through versioning and compatibility, so it was interesting to read what Microsoft do here. The Zalando guidelines take a different approach, using media types for versioning, document just one set of compatibility rules, plus a deprecation model, and it's working very well in practice so far ([http://zalando.github.io/restful-api- guidelines/compatibilit...](http://zalando.github.io/restful-api- guidelines/compatibility/Compatibility.html)).

Btw, in case anyone from Microsoft working on the guidelines is reading and ever wanted to swap guideline notes or ideas, that would be awesome. And once again, great job releasing the doc :)

</comment><comment><USER20> [https://evertpot.com/dropbox-post-api/](https://evertpot.com/dropbox-post- api/)

This discuss some option for the GET vs POST.

In Kibana, everything is done over GET as get parameters, and I find that extremely annoying and a poor design.

A lot of public APIs also don't honor or have any intentions in supporting or using PATCH. Most APIs I have worked with only use PUT for modification. Anything resembles "creation" is automatically a POST.

<comment><USER21> > In Kibana, everything is done over GET as get parameters, and I find that > extremely annoying and a poor design.

Kibana (4.x) being a website to display queries and some charts and weighing over hundred megabytes is itself a clear example of a poor design.

<comment><USER20> We ran into a situation exactly like that. We hit the limit of the length of GET.

Thanks.

</comment></comment></comment><comment><USER22> Very cool document. I kind of got stuck at delta queries, though. How do you implement that? I can't find any reference to delta/removed queries on Mongo, Postgres, or MySQL. Do you just keep all records in the database and add a "removed" field? How would that solution work with user privacy & users truly wanting to remove data?

<comment><USER9> Delta queries are pretty easy, assuming you have a rich data store behind your data.

As others have said, your data store needs to be able to say, "Show me changes since XYZ". Most of the Big Apps can do that, and from there the problems is one of API Semantics.

This doc addresses the API Semantics, rather than the application design. To try to solve the design problem would be impossible as every application is different.

<comment><USER22> I understand what the doc is trying to convey, I just hadn't ever thought of the application-level logic for record deltas before, so I got incredibly distracted from the document. It made me wonder how other people, not using temporal tables, are accomplishing this right now.

<comment><USER9> I don't think I've ever seen delta's done at-scale with actual temporal tables, but rather with transaction Id's of some sort.

For example (based on the doc) when you register a delta link, there's a row written to Azure Tables saying, "owner:iheart2code, deltaToken:foo, lastRecordIdSeen:123".

When you then make the Delta request, we look up "foo" for you, find that the last id you've seen is 123, and then only give you records from the transaction table with an id larger than that.

Temporal is always a can of worms, as clocks are impossible to keep in sync and there are endless race conditions.

Making the delta tokens causal, rather than temporal, is the way to go. Anything else is brutal in the distributed systems world...

</comment></comment></comment></comment><comment><USER23> Interesting to see Microsoft talk about "human-readable URLs". I still remember the mess kb.microsoft (or the surrounding MS infra) was at a time.

Nice to see them support such stuff, still.

</comment><comment><USER24> Seems ... strange to bash their own "Best Way to REST" offering, OData [0]

[0]: [http://www.odata.org](http://www.odata.org)

</comment><comment><USER25> Funny thing: I've been thinking a bit about API versioning quite a bit lately, and the best solution I've come up with is the ONE thing not at all covered in this: put an `api-version` header into the request. I've seen both of the schemes recommended here, and I like neither very much. So what's wrong with my (header) solution?

<comment><USER26> Neither of the schemes mentioned here are good as they change the URI for a resource, which breaks all sorts of things. Could you imagine if every website wanting to switch from HTML 4 to HTML 5 had to update their URIs from [https://www.example.com/HTMLv4/contact.html](https://www.example.com/HTMLv4/contact.html) to [https://www.example.com/HTMLv5/contact.html](https://www.example.com/HTMLv5/contact.html)? It would be chaos.

For instance, if client application A talks to the service using version 1.0 of the API and client application B talks to the service using version 2.0 of the API, then those client applications can't interoperate because they are seeing two different sets of resources.

Your solution isn't far off the approach recommended by everybody who rejects the different URI approach. You don't need an API version header. When your representation format for a resource changes, provide a `version` parameter for the media type. For example: `Content-Type: application/vnd.example.foo+json;version=2`.

This is exactly how HTTP and the `Content-Type` header are supposed to work – if your representation for a resource changes, you don't change the URI, you change the media type.

<comment><USER9> The "?api-version" approach in the doc is there for exactly the reason you call out. Azure uses this approach.

By omitting "/v1.0" from the path it makes the actual URL's far more durable, as they're not version dependent. There are pros and cons to this, as there is with everything. In Azure's case it's great, as you can then use URLs as resource identifiers and put ACL's on them. If they were versioned via the path, this wouldn't work.

Other services, such as XBox, and (very old) Azure, put the API version in a custom header (x-ms-version, for example). This proved to be extremely problematic, and every team that does this had stories of all the problems it caused and then spends time removing it.

I've never seen a detailed proposal for putting API version in the Content- Type header, and will go look.

The content-type header does seem to have many of the same drawbacks as putting the version in a header (any header). For example, people could not make queries from a browser just by entering a URL as there is no way to specify a header. Nor could someone bookmark an API GET request, which is also quite handy.

Ease of use is huge, and I am in the camp that a version in the URL (path or parameter) is much easier in every way than a header. Every with curl, it's easier (I can never remember how to specify headers w/o the man page).

<comment><USER27> One slight downside of a custom header to specify a version is that OPTIONS calls don't include the value of the custom header, so your pre-flight gets to say yes or no without knowing what version is being called. Putting API version in the URL or query string fixes this.

As for bookmarking a GET request, this is /almost/ doable even following the MSFT guidelines since it says that service implementors MUST also provide a query-string alternative to required custom headers (section 7.8), and that service implementors MUST support explicit versioning. The only fly in this ointment is that the versioning part of the spec only offers two places of specifying the version - URL and query string, and seems to leaves no room for other options.

Personally, I think the Accept header flavor with custom MIME types is the most flexible for minor (backwards compatible) version - see GitHub's API for an example - but it certainly isn't the most simple to work with, neither in client libraries, Curl/WGet command-line use or API consumer tools (almost none let you fiddle with Accept headers). Since API ease of use is such a big factor for adoption, passing versions in the URL or the query string is most likely an OK lowest common denominator for APIs that seek the widest possible reach.

</comment></comment></comment></comment><comment><USER28> Roy Fielding thinks this isn't REST. He says REST APIs != HTTP APIs. So, read with caution. Also, I noticed the MSFT guide doesn't mention HATEOS.

<comment><USER29> HATEOS is one of the steps too far that contributed in making REST suck more for everyone.

People following this also tend to follow it like a dogme, and find that their APIs are slow, too meta/abstract, and hard to consume.

</comment></comment><comment><USER30> Being that guy again, (and sacrificing my karma) but...

This is not REST, it contains nothing about hypermedia, entities having knowledge of their URIs, or any way of discovering features of an API programmatically.

While I'm sure there's plenty of good stuff in here (it looks otherwise fairly comprehensive), APIs will continue to be a disparate system that requires custom code for every integration until we can embrace the full benefits of REST, and develop the technology and conventions/standards for integrating RESTful services.

Edit: for an example of what's possible with 'real' REST, check out this talk: [https://vimeo.com/20781278](https://vimeo.com/20781278) – better documentation, easy parsing, API optimisation without client changes, discovery, and the API is fully human readable/usable as well.

<comment><USER31> REST seems like an elephant in a room with some blind folks. Everybody who touches it thinks it's something different than the next guy, and they're all describing only one element of the thing.

That said, I don't actually know what this elephant looks like, either, because everybody I've read on the subject seems to have only a partial understanding of it...thus, I have a partial understanding of it.

If you know what the whole elephant looks like, and have good resources for what makes something _actually_ REST, I'd be interested.

<comment><USER32> The best way to understand REST is by example. First check out the blog post by Roy Fielding mentioned in this thread which summarizes the constraints [1]. Then let's examine how several popular restful services work versus those constraints.

Here are some popular well-known services to use as examples: Google.com Amazon.com Facebook.com News.ycombinator.com.

\- You enter these services through the site root with no prior knowledge about the services aside from standard media types (HTML/CSS/JS)

\- Hypermedia is the engine of application state – meaning that you load a webpage a.k.a. resource that contains hypermedia links to other resources, and you navigate between states in the application by following those hypermedia links. For example, the hacker news homepage contains links to news articles and comment threads about them, which contains links to reply to those comments, and so on.

\- The application describes how to compose requests using standard media types such as web forms and JavaScript. Because the pages instruct the client about what requests to compose and to which URL, the services have control over their own name spaces which have no fixed resource names or hierarchy.

I consider REST to be most easily understood as a departure to application protocol design prior to the Web, where each application and service had a unique and custom binary protocol, and a client for these services had to be reprogrammed to interact with it. REST is a set of constraints for designing services that run at Internet scale and that highly decouples clients and servers. Fielding's thesis on REST has more detail on the principles by which the REST architectural style was derived.

[1] [http://roy.gbiv.com/untangled/2008/rest-apis-must-be- hyperte...](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext- driven)

<comment><USER33> The big problem with using the hypertext Web as an example of REST is that there is a human operator literally driving that "engine of application state". Most API clients cannot afford to compute their state transitions on a network of 80 billion neurons.

<comment><USER26> No there isn't, a great deal of the web is loaded without direct human requests. For example:

* Web crawlers

* Archival services

* Embedded resources (stylesheets, JavaScript, images)

* Newsfeeds

<comment><USER34> All those examples are hard coded algorithms in the bulk copy category. They pretty much just use the GET method to download all or a specific subset of a site.

To truly drive a REST API requires a human or an AI. The AI doesn't need to be human equivalent, just smart enough to inteligently interpret the hypermedia. If the API changes the AI would be able to adapt.

I'm talking about the complexity of the computer on the Enterprise in ST:TNG. You give it a command and it figures out how to go about solving it.

<comment><USER26> I don't know where you got the idea that REST needs futuristic AI, and you haven't really explained why you think that way.

Why does a REST client have to _intelligently_ interpret the hypermedia? Why are hard-coded algorithms a problem? Why does it need to adapt to changes in the API? None of those things are requirements for REST, you've inserted them for seemingly no reason.

For instance, consider an unattended webcam you want to use to show off, e.g. the growth of a flower bed remotely. It has the URI for a web service that returns a resource describing actions it can take:

        {
            "actions": [
                {
                    "rel": "report-problem",
                    "href": "https://example.com/report-problem",
                    "method": "POST",
                    "accept": "application/problem+json"
                },
                {
                    "rel": "update-frame",
                    "href": "https://example.com/update-frame",
                    "method": "POST",
                    "accept": "image/*"
                }
            ]
        }

The definition of the report-problem relationship is "This is the action to take when an error occurs."

The definition of the update-frame relationship is "This is the action to take when a new frame is available to upload."

This API defines one media type and two relationships. It requires no futuristic artificial intelligence or human intervention, it just needs to speak HTTP, parse simple JSON, and trigger the actions based on simple conditions.

<comment><USER33> It also doesn't provide much benefit over a plain RPC-like interface, because, for practical reasons, the webcam will be coded to send requests directly to [https://example.com/report-problem](https://example.com/report-problem) and [https://example.com/update-frame](https://example.com/update-frame) (the "bookmarks"). If you want to change those URLs, your best hope is that the webcam will understand a 307 or 308 redirect.

<comment><USER26> RPC vs REST is an entirely different argument. We're talking about REST best practices here, not "let's do RPC instead".

There's no reason for the webcam to hard-code URIs, and that's a violation of the architectural constraints. Just arbitrarily deciding to disregard facets of the architectural pattern without giving a reason does not add to this discussion.

None of this relates to whether or not you need futuristic AI or human intervention. I think from the example, it's pretty clear you need neither for a REST API.

<comment><USER33> > We're talking about REST best practices here, not "let's do RPC instead".

I don't think so. Avernar above seems to argue against REST as an architectural style (RPC being the default as everybody uses it). I thought you were trying to defend REST with your example, and I wanted to point out a weakness in that example.

> There's no reason for the webcam to hard-code URIs, and that's a violation > of the architectural constraints.

The webcam has to hardcode _some_ URIs (entry points). Consider that it could be using other services: perhaps a social network to post updates on. Then it must hardcode another entry point URI. But at that point -- and since every resource is supposedly independent and only explicit relations matter -- why can't the webcam treat the "problem report service" and the "update frame service" as two entirely separate services to hardcode? Which constraint of REST does this violate?

In your example, insisting that the webcam go through the entry point doesn't even buy the server a lot of flexibility. You reduce the client's knowledge from 2 URLs to 1 URL -- a URL that you may still want to change etc.

An extra HTTP roundtrip every time can well be an unpleasant overhead. HTTP client caches are sparsely supported and notoriously complex (RFC 7234 is 41 pages long). Rolling your own cache is, well, rolling your own.

And then there is the human problem. I was blown away by a discussion [1] where people reported using _cryptography_ to prevent _in-house_ clients from hardcoding URLs. I was also saddened when I read the JSON API spec [2] -- a great example of REST, I think -- only to discover that most existing implementations [3] disregard the linking aspect and hardcode the URL structure that the spec uses for examples. But this is not a complaint against your webcam example so much as it is a general hurdle with REST.

[1] [http://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid- ha...](http://blog.ploeh.dk/2013/05/01/rest-lesson-learned-avoid-hackable- urls/) [2] [http://jsonapi.org/](http://jsonapi.org/) [3] [http://jsonapi.org/implementations/](http://jsonapi.org/implementations/)

> None of this relates to whether or not you need futuristic AI or human > intervention. I think from the example, it's pretty clear you need neither > for a REST API.

Absolutely.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> Jeez... anyone else find the caps hurting the eyes? Is it necessary? Sorry I have nothing constructive to add. Just had to bring this up.

</comment><comment><USER36> Wow, they REALLY LIKE TO SHOUT THEIR HEADINGS.

Otherwise, what I've read so far looks like a really good start. Say what one will about Microsoft's products, but there are a lot of smart folks there.

<comment><USER37> From the same people who brought you the XML SOAP API. Smart people. Too smart?

</comment></comment><comment><USER38> Surprised people are still talking about REST after GraphQL

</comment><comment><USER38> Surprised people are still talking about REST after Facebook unveiled GraphQL</comment>


Apple launches three innovative studies today in the new Research app - <AUTHOR> https://www.apple.com/ios/research-app/ <comment><USER2> This is a great way to begin a research health case for apple users. Android gets left out and the Google conflict of interest will be an interesting battle.</comment>