5 ms·

> There is also a GET request to https://news.ycombinator.com/collapse?id=1234567 https://news.ycombinator.com/collapse?id=1234567 to save the state of the coll

> There is also a GET request to https://news.ycombinator.com/collapse?id=1234567 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'?

TheSoftwareGuy 7y ago
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.
- Ajedi32 7y ago
  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-sync https://developers.google.com/web/updates/2015/12/background...
  - dmix 7y ago
    That's a pretty big downside.
    - moftz 7y ago
      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.
    - dmurray 7y ago
      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.
  - jedberg 7y ago
    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.
- koolba 7y ago
  Should be a PUT as the operation is idempotent.
- duxup 7y ago
  Man that gave me some ideas regarding some users I have who have crappy internet connections ....
dexen 7y ago
>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 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 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...
- cheschire 7y ago
  The weight of a well used ellipsis...
- hjek 7y ago
  The 'logout' button is also a GET request.
- baddox 7y ago
  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.
- merb 7y ago
  with get you can also have multiple inserts when some network things break. because get requests might be retried.
rolltiide 7y ago
why not store this state client-side?
- kawsper 7y ago
  I might visit Hackernews using multiple user-agents.
  - bm5k 7y ago
    is cross-session comment folding really that important/neat?
    - toomuchtodo 7y ago
      Yes! It's subthread "marked as read" or "hide".
    - LanceH 7y ago
      I would say it's more important than caring if something is a GET or POST on the backend.
    - PopeDotNinja 7y ago
      I like it. One of my favorite features.
  - rolltiide 7y ago
    then why not do it client side and bundle state saving later.
nicolaslem 7y ago
Isn't that vulnerable to CSRF? What if a page linked on the front of HN makes a request collapsing every single comment?
- slg 7y ago
  One of the top posts in the history of HN was a link that upvoted itself due to this issue.
- thepete2 7y ago
  Yes, but you need a token to log out. For collapsing comments it should work though
  - thepete2 7y ago
    correction: same origin policy, so it doesn't work
    - lol768 7y ago
      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.
justinhj 7y ago
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
- skohan 7y ago
  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.
  - justinhj 7y ago
    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.
- jedberg 7y ago
  > 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.
thewarpaint 7y ago
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/ http://thewarpaint.github.io/hyperlogout/

TheSoftwareGuy 7y ago

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.

Ajedi32 7y ago
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-sync https://developers.google.com/web/updates/2015/12/background...
- dmix 7y ago
  That's a pretty big downside.
  - moftz 7y ago
    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.
  - dmurray 7y ago
    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.
- jedberg 7y ago
  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.
koolba 7y ago
Should be a PUT as the operation is idempotent.
duxup 7y ago
Man that gave me some ideas regarding some users I have who have crappy internet connections ....

dexen 7y ago

>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 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 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...

cheschire 7y ago
The weight of a well used ellipsis...
hjek 7y ago
The 'logout' button is also a GET request.
baddox 7y ago
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.
merb 7y ago
with get you can also have multiple inserts when some network things break. because get requests might be retried.

rolltiide 7y ago

why not store this state client-side?

kawsper 7y ago
I might visit Hackernews using multiple user-agents.
- bm5k 7y ago
  is cross-session comment folding really that important/neat?
  - toomuchtodo 7y ago
    Yes! It's subthread "marked as read" or "hide".
  - LanceH 7y ago
    I would say it's more important than caring if something is a GET or POST on the backend.
  - PopeDotNinja 7y ago
    I like it. One of my favorite features.
- rolltiide 7y ago
  then why not do it client side and bundle state saving later.

nicolaslem 7y ago

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

slg 7y ago
One of the top posts in the history of HN was a link that upvoted itself due to this issue.
thepete2 7y ago
Yes, but you need a token to log out. For collapsing comments it should work though
- thepete2 7y ago
  correction: same origin policy, so it doesn't work
  - lol768 7y ago
    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.

justinhj 7y ago

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

skohan 7y ago
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.
- justinhj 7y ago
  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.
jedberg 7y ago
> 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.

thewarpaint 7y ago

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/ http://thewarpaint.github.io/hyperlogout/