[HN Gopher] Triptych Proposals
___________________________________________________________________
Triptych Proposals
Author : felipemesquita
Score : 76 points
Date : 2025-01-06 20:52 UTC (2 hours ago)
(HTM) web link (alexanderpetros.com)
(TXT) w3m dump (alexanderpetros.com)
| netcraft wrote:
| I love these. Its the things we've been doing (or attempting to
| do) with our web pages for decades. I've written tons of jquery
| to do these exact things, lots of react code as well.
|
| I think its an uphill battle, but I am hopeful.
| ttymck wrote:
| Looks really pragmatic and I'd be glad to see this succeed.
|
| Is anyone able to credibly comment on the likelihood that these
| make it into the standard, and what the timeline might look like?
| recursivedoubts wrote:
| Alex is working on it now and we have contacts in the browser
| teams. I'm optimistic but it will be a long term (decades)
| project.
| tinthedev wrote:
| It looks wonderful, but the adoption will be a thoroughly uphill
| battle. Be it from browsers, be it from designs and
| implementations on the web.
|
| I'll be first in line to try it out if it ever materializes,
| though!
| motoboi wrote:
| JSON rest api are just hypermedia rest api but with the data
| compressed. The compression format is json and the dictionary are
| the hypermedia relations previously passed in the client.
|
| It's 2025, the client don't need to be generic and able to surf
| and discover the internet like it's 2005.
|
| The database is consumed via APIS distributed in two parts: first
| the client (a lib), second the data: json.
| recursivedoubts wrote:
| No, they aren't.
|
| https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
|
| Your client is already generic you just aren't using that
| functionality:
|
| https://htmx.org/essays/hypermedia-clients/
| colordrops wrote:
| Maybe just give up the ghost and use a new unambiguous term
| instead of REST. Devs aren't going to let go of their JSON
| apis as browsers often are not the only, or even main,
| consumers of said APIs.
|
| Creating frameworks and standards to support "true" RESTful
| APIs is a noble goal, but for most people it's a matter of
| semantics as they aren't going to change how they are doing
| things.
|
| A list of words that have changed meaning, sometimes even the
| opposite, of their original meaning:
|
| https://ideas.ted.com/20-words-that-once-meant-something-
| ver...
|
| It seems these two discussions should not be conflated: 1.
| What RESTful originally meant, and 2. The value of RESTful
| APIs and when they should and shouldn't be used.
| alexpetros wrote:
| It sounds like the client you're describing is less capable
| than the client of 2005, and I'd be curious to hear why you
| think that's a good thing.
| cryptonector wrote:
| The problem with RESTful requiring hypermedia is that if you
| want to automate use of the API then you need to... define
| something like a schema -- a commitment to having specific
| links so that you don't have to scrape or require a human to
| automate use of such an API. Hypermedia is completely self-
| describing _when you have human users involved_ but not when
| you don 't have human users involved.
| mg wrote:
| What is the upside of <button
| action="/users/354" method="DELETE"></button>
|
| over <button
| action="/users/delete?id=354"></button> ?
| recursivedoubts wrote:
| implied idempotence
| AndrewHampton wrote:
| What HTTP method would you expect the second example to use?
| `GET /users/delete?id=354`?
|
| The first has the advantage of being a little clearer at the
| HTTP level with `DELETE /users/354`.
| mg wrote:
| GET because that is also the default for all other elements I
| think. form, a, img, iframe, video...
|
| Ok, but what is the advantage to be "clear at the http
| level"?
| lionkor wrote:
| Well, its correct, so its likely to be optimized correctly,
| to aid in debugging, to make testing easier and clearer,
| and generally just to be correct.
|
| Correctness is very rarely a bad goal to have.
|
| Also, of course, different methods have different rules,
| which you know as an SE. For example, PUT, UPDATE and
| DELETE have very different semantics in terms of
| repeatability of requests, for example.
| necubi wrote:
| GET shouldn't be used for a delete action, because it's
| specified as a safe method[0], which means essentially
| read-only. On a practical level, clients (like browsers)
| are free to cache and retry GET requests, which could lead
| to deletes not occurring or occurring when not desired.
|
| [0]
| https://datatracker.ietf.org/doc/html/rfc7231#section-4.2.1
| recursive wrote:
| GETs have no side effects, by specification. DELETEs can
| have side effects.
| thayne wrote:
| A GET request to `/users/delete?id=354` is dangerous. In
| particular, it is more vulnerable to a CSRF attack, since a
| form on another domain can just make a request to that
| endpoint, using the user's cookies.
|
| It's possible to protect against this using various techniques,
| but they all add some complexity.
|
| Also, the former is more semantically correct in terms of HTTP
| and REST.
| alexpetros wrote:
| Hey there, good question! Probably worth reading both sections
| 6 and 7 for context, but I answer this question specifically in
| section 7.2: https://alexanderpetros.com/triptych/form-http-
| methods#ad-ho...
| recursivedoubts wrote:
| this is a set of proposals by Alex Petros, in the htmx team, to
| move some of the ideas of htmx into the HTML spec. He has begun
| work on the first proposal, allowing HTML to access PUT, DELETE,
| etc.
|
| https://alexanderpetros.com/triptych/form-http-methods
|
| This is going to be a long term effort, but Alex has the
| stubbornness to see it through.
| alexpetros wrote:
| Co-author here! I'll let the proposal mostly speak for itself but
| one recurring question it doesn't answer is: "how likely is any
| of this to happen?"
|
| My answer is: I'm pretty optimistic! The people on WHATWG have
| been responsive and offered great feedback. These things take a
| long time but we're making steady progress so far, and the
| webpage linked here will have all the status updates. So, stay
| tuned.
___________________________________________________________________
(page generated 2025-01-06 23:00 UTC)