341–350 of 361 posts
Earlier quoted context omitted.
As in, anybody with a link to /delete could delete things? No identification/authentication/authorization needed?
> I spent the next few days fixing several of problems that conspired to make that happen... Yes, I was a total n00b in 2001. But then, so was e-commerce.
It took a lot of tweaking to give it the right feel. imho it shouldn't start fetching to fast in case the mouse is only moved over the link. Loading to many assets at the same time is also bad. Some should preload with a delay and hovering over a different link should discontinue preloading the previous assets.
Perhaps there is room for a paid version that crawls the linked pages a few times and preloads static assets. Who knows, perhaps you could load css, js and json as well as images and icons.
Or (to make it truly magical) make the amount of preloading depend on how slow a round trip resolves. If loading the favicon.ico (from the users location) takes 2+ seconds the html probably wont arrive any time soon.
Fun stuff, keep up the good work.
[1]- http://web.archive.org/web/20130329183223/http://widgets.ope...
Earlier quoted context omitted.
FWIW RFC 2616 was obsoleted by the newer HTTP/1.1 RFCs: https://tools.ietf.org/html/rfc7231#section-4.2
Which still doesn't change GP's point though: > 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. These methods ought to be considered "safe". (there's an exception listed too, but doesn't apply to logout) EDIT: I know of someone who made a backup of their wiki by simply doing a crawl - only to find out later tha…
Earlier quoted context omitted.
Similar in effect, but not in method. Turbolinks fetches pages after a click like normal, but swaps the body tag from the new page into the current page, cutting local render times.
Would it make sense to combine them? Instant turbo links.
Earlier quoted context omitted.
Idempotency has nothing to do with it. Deleting a resource is idempotent as well. You wouldn't do that via GET /delete A GET request should never, ever change state. No buts. Just because a bunch of well known sites use GET /logout to logout does not make it correct. Doing anything else as demonstrated in this and other cases breaks web protocols, the right thing to do is: GET /logout returns a page with a form butto…
Depends on your definition of “state.” A GET to a dynamic resource can build that resource (by e.g. scraping some website or something—you can think of this as effectively what a reverse-proxy like Varnish is doing), and then cache that built resource. That cache is “state” that you’re mutating. You might also mutate, say, request metrics tables, or server logs. So it’s fine for a GET to cause things to happen—to cha…
> So, by this measure, the old-school “hit counter” images that incremented on every GET were incorrect
Yes they are incorrect. No Buts.
Two requests hitting that resource at the same exact timestamp would increase the counter once if a cache was in front of it.
Many people browse the web from an employer who has rules about what types of pages may be accessed. For example, a person applying for a job with my team may include a link to a web page about their job-related background -- portfolio.html or whatever. HR tells us to be sure we don't follow links to any other page that may be more personal in nature, such as a page that reveals the applicant's marital status (which…
P.S: Using HN at my office. Was looking at career pages of other software companies a while ago.
Earlier quoted context omitted.
A logout action is idempotent, though. You can't get logged out twice. In my opinion, that's the use case for a GET request. I just checked NewRelic, Twilio, Stripe and GitHub. The first 3 logged out with a GET request and GitHub used a POST.
Idempotence is for PUT requests. GET requests must not have side effects.
For example: Let's implement authentication, where a user logs in to your api and receives a session id to send along with every api call for authentication. The session should automatically be invalidated after x hours of inactivity.
How would you track that inactivity time, if you're not allowed to change state on get requests?
Earlier quoted context omitted.
A logout action is idempotent, though. You can't get logged out twice. In my opinion, that's the use case for a GET request. I just checked NewRelic, Twilio, Stripe and GitHub. The first 3 logged out with a GET request and GitHub used a POST.
Idempotency has nothing to do with it. Deleting a resource is idempotent as well. You wouldn't do that via GET /delete A GET request should never, ever change state. No buts. Just because a bunch of well known sites use GET /logout to logout does not make it correct. Doing anything else as demonstrated in this and other cases breaks web protocols, the right thing to do is: GET /logout returns a page with a form butto…