Hacker News Reader

Comment by llamathrowaway | Hacker News Reader

> There is also a GET request to https://news.ycombinator.com/collapse?id=1234567 to save the state of the collapsed/expanded comment if the user is logged in, but it's an async request so it doesn't have an impact.

Is this a correct place to use 'GET'?

View on HN

>Is this a correct place to use 'GET'?

Not at all; GET requests are specified [0] to not cause any modifications to the resources (aside of meta-data like logging etc.). It should also be 100% safe for web spiders to issue any GET at any time [1], server overload aside.

I presume it's an artifact of earlier implementation -or just an idea- to have the collapse work without JavaScript. It would be doable with a normal A HREF with the current link format of https://news.ycombinator.com/collapse?id=20336970

[0] "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval." - https://tools.ietf.org/html/rfc2616#section-9.1.1

[1] in the early day of the internet, a friend lost most of his CRM's content because he had record deletes implemented as A HREF issuing GET requests. Having learned the lesson, he instead turned to JavaScript code issuing GETs...

The weight of a well used ellipsis...

The 'logout' button is also a GET request.

I thought that the normal way to have this work without JavaScript would be to have a form tag with the submit button styled to look like the collapse button.

with get you can also have multiple inserts when some network things break. because get requests might be retried.

It does modify state on the server so I would think it should be a POST or something.

even better, they could do what reddit does with upvotes/downvotes, and store that information in the user's cookie, so that it gets sent with the next request to the server.

I never realized Reddit did that. That's a really cool hack; like a poor man's version of Background Sync[1]. I guess the disadvantage of using cookies is that if you just click to vote and then close the tab, your vote might not be recorded for a long time.

[1]: https://developers.google.com/web/updates/2015/12/background...

That's a pretty big downside.

They probably figure that with the amount of clicking on threads that people on reddit do that the site will capture almost everything except for that very last page you upvoted on before you closed the tab and went to bed. However, you're probably getting on reddit soon anyway and the votes will be counted then.

It's fine for Reddit's purposes. Randomly losing 10% of voting interactions wouldn't be a big deal for them. Of course, that wouldn't be ok for many other applications.

I'm pretty sure they save it in the cookie and fire off a POST at the same time in an async thread and then don't check if the request succeeded. That way it's a backup if you're on crappy internet or the server was down or something.

The cookie isn't the only way the vote gets there.

Should be a PUT as the operation is idempotent.

Man that gave me some ideas regarding some users I have who have crappy internet connections ....

Following the rules of REST is very important if you are presenting a public API to the world. If it's your own server you can do whatever you want. For example I used to work on servers for games and often there would be a single endpoint for processing one or more commands, and this would be technically a GET request regardless of what those commands did. Furthermore it's common to send application level error details with a 200 status code; i.e the http level transaction succeeded but the application layer produced an error. Much heated discussion emerges around these design choices :D

As you say it will work just fine as long as your client and server agree, but free-wheeling it with the HTTP spec can come with operational drawbacks.

I've worked with a lot of different internal webservices as a freelancer, and if they're reasonably RESTful and built according to spec, it's easy to just get started with the codebase. Ones like you're describing mean a lot more conversations and reading through code.

Of course it depends on the nature of your team and how often you on-board, but to me the HTTP spec is one of those things like following coding style conventions: sure you don't need to do it, but at the end of the day it's not that much more work once you're in the habit, and it makes it that much easier to work with other people.

I absolutely agree with your points, and that's good advice as long as your application works by modifying resources of a single type with each request. In my specific case we wanted to reduce round trips to the server by using compound commands that may do multiple things on the backend, affecting multiple entity types that would have to be, in rest, a resource. Also in our case my team was responsible for the client and the server, and the commands/responses are clearly documented for everyone to see.

> If it's your own server you can do whatever you want.

This is not at all true. For example, say I'm a user in a dorm that uses a proxy that I have no control over. If you make your GET request modify things, that proxy may cache the request, or worse, may repeat the request later to maintain its cache.

My point is, you don't know what is between your server and their client, and even well behaved infrastructure will sometimes make or modify GET requests on your behalf, but won't do that with POSTs.

It's also an issue when you don't even fully control the client, which in this case is the web browser. A game at least behaves exactly as you program it. Browsers are not necessarily consistent, especially when you throw in extensions.

Yes excellent point. Some browsers/plugins will prefetch every GET on the page to speed up browsing.

Some browsers also show a "here's your top 10 most visited webpages" shortcut when you make a new tab, which does a GET. I ran into that one when I was being lazy about building/testing an API.

In the Hacker News case there isn't a GET request on the page, it's triggered by the javascript so this would not happen

There are ways to make sure that your GET requests are not cached. For example in the case we're talking about here the server sets that URI to have "Cache-Control: private; max-age=0". Now sure, a proxy could simply ignore HTTP protocol and cache it anyway, but that would break a lot of things and AFAIK is not seen often in the wild. Certainly in the case of the applications I worked on we did not have customers that reported connection difficulties over HTTP.

Isn't that vulnerable to CSRF? What if a page linked on the front of HN makes a request collapsing every single comment?

One of the top posts in the history of HN was a link that upvoted itself due to this issue.

Yes, but you need a token to log out. For collapsing comments it should work though

correction: same origin policy, so it doesn't work

SOP isn't relevant here - it relates generally to _reading_ content from another origin.

What is relevant here is whether the cookies are SameSite and/or whether a token is required.

Tangentially related: I once built a page that logged you out of several services which implemented logout as GET requests (HN included). WARNING: might be better to visit it in incognito mode.

http://thewarpaint.github.io/hyperlogout/

why not store this state client-side?

I might visit Hackernews using multiple user-agents.

is cross-session comment folding really that important/neat?

Yes! It's subthread "marked as read" or "hide".

I would say it's more important than caring if something is a GET or POST on the backend.

I like it. One of my favorite features.

then why not do it client side and bundle state saving later.

Reply on news.ycombinator.com