undefined | Better HN

0 pointswilliamdclt1y ago0 comments

I mean, it should just be a submit for a form with a /logout POST action. It’s standard and what web devs have been doing for decades

0 comments

recursivedoubts1y ago

Yeah, the problem is that it requires a form, which has layout implications w/o styling and POST is not idempotent, whereas a logout operation typically is idempotent. Being able to issue a DELETE to a URL like /session from an element that doesn't have layout implications would be ideal.

de46le1y ago

A button doesn't have to be inside a form, though. You could have an empty form as a neighbour to the button (or anywhere else inside the page body), and associate the button with it.

  <button form="logout-form" ...>logout</button>
  <form name="logout-form"></form>

No layout implications that way, barring any nth-child css (solvable by putting the form somewhere else). Doesn't solve the form being limited to GET/POST, but styling concerns are atleast handled.

recursivedoubts1y ago

doable but rarely used, inconvenient and awkward, alex proposes allowing buttons to be stand-alone hypermedia controls which also allows multiple buttons located within a form to perform different actions (e.g. save v. cancel)

1 more reply

williamdcltOP1y ago

> POST is not idempotent

It certainly can be, there’s just no _requirement_ that it is idempotent. There’s no problem with having an idempotent POST operation.

I’m also not a fan of a DELETE /session option, the client shouldn’t have to care about the concept of “session”, it’s the server’s problem. But I’m not a fan of resource-based endpoints in general, I tend to prefer task-based endpoint so /logout makes more sense to me.

Also, even if it was possible to trigger DELETE in html it probably would be implemented as a form. Not really a problem, making a form element inline is trivial, and probably needed in various parts of an app (any button that changes some state)

recursivedoubts1y ago

right, but the browser doesn't know that and so it has to treat the operation as if it were not idempotent (i.e. warn on a resubmit)

You second paragraph indicates that you do not like the REST pattern of the web, which is fine, but i hope you can appreciate that some of us would like the web as the web to make it possible to abide by that pattern

the last point is addressed in Alex's proposal to allow buttons to function as stand-alone hypermedia controls

j / k navigate · click thread line to collapse

0 comments

recursivedoubts1y ago

de46le1y ago

A button doesn't have to be inside a form, though. You could have an empty form as a neighbour to the button (or anywhere else inside the page body), and associate the button with it.

  <button form="logout-form" ...>logout</button>
  <form name="logout-form"></form>

No layout implications that way, barring any nth-child css (solvable by putting the form somewhere else). Doesn't solve the form being limited to GET/POST, but styling concerns are atleast handled.

recursivedoubts1y ago

1 more reply

williamdcltOP1y ago

> POST is not idempotent

It certainly can be, there’s just no _requirement_ that it is idempotent. There’s no problem with having an idempotent POST operation.

recursivedoubts1y ago

right, but the browser doesn't know that and so it has to treat the operation as if it were not idempotent (i.e. warn on a resubmit)

the last point is addressed in Alex's proposal to allow buttons to function as stand-alone hypermedia controls

j / k navigate · click thread line to collapse