5 ms·

I can only assume this whole post is meant as a joke. HCF obviously. HELP and BUY are throwbacks to when protocols were designed with interactivity in mind, and

by knome 4y ago

I can only assume this whole post is meant as a joke. HCF obviously. HELP and BUY are throwbacks to when protocols were designed with interactivity in mind, and are useless today. UNDO and REMEMBER are also without merit, the former implying statefulness on the server's part (if the client is sending the state to undo to, it's just PUT), and the latter being impossible to implement (could not distinguish browsers behind NAT, or running on same box, etc).

robryk 4y ago
UNDO makes sense if the server is keeping a bag of responses. For example, ActivityPub has an Undo action that points at a previous action punished by the same user. You use it to unfollow, unvote, unfavorite, etc. Obviously, handling of Undo has to be at least partially specific to the thing being undone, but they are all expressed using the same primitive.
- arinlen 4y ago
  > UNDO makes sense if the server is keeping a bag of responses. I disagree. Any UNDO action is just a DO action with a spcific set of commands executed in a specific order. If you use POST and PATCH and DELETE to apply actions, not only can you replay them but you can also trivially support a POST /resource/<resourceId>/undo. This is particularly relevant in systems that employ an event sourcing of some sort.
freedomben 4y ago
Yeah, it's gotta be a joke. The only one that actually sounds useful to me is HELP. I have to disagree with you on that one, a HELP that could explain the endpoint and verbs? that would be AWESOME. kind of like `kubectl explain`, which has been helpful to me on multiple occasions. Of course 99% of apps would not implement that, but frameworks could easily give you that for free as the dev, and reuse the declarative code that already exists in the router... There are already tools that generate swagger files and such, seems like it wouldn't be much harder to render a server response/document on demand. You could even serve a beautiful doc page viewable in a browser! The more I think on this, the more I like it.
- Joker_vD 4y ago
  That's pretty much just entrypoint for HATEOAS, isn't it?
- hn_throwaway_99 4y ago
  FWIW, this is a huge benefit of GraphQL. All GraphQL servers that publish their schemas can instantly have their schemas loaded with full documentation and an interactive execution environment with GraphQL Playground.
  - capableweb 4y ago
    Is it really a distinct benefit though since something similar to that have been existing for a really long time before GraphQL already? From OpenAPI/Swagger all the way back to HATEOS/HAL and RDF, if not even earlier.
    - freedomben 4y ago
      I'm not generally a fan of graphql, but yes it's a remarkable feature. The other options (like swagger) take more effort and tend to not be maintained well. But even when they are, it's still not as developer friendly (to the client) as graphql.
    - eurasiantiger 4y ago
      It is a distinct benefit when your query playground is schema-aware and can suggest completions for types, fields and field (query) parameters, as well as validate everything pre-request.
    - hn_throwaway_99 4y ago
      I've worked with all of those options before I started working with GraphQL. The "out-of-the-box" support, especially the standardization that GraphQL enforces with its schema definition, is/was night-and-day compared to something like Swagger.
- adeel_siddiqui 4y ago

by knome 4y ago

robryk 4y ago

UNDO makes sense if the server is keeping a bag of responses. For example, ActivityPub has an Undo action that points at a previous action punished by the same user. You use it to unfollow, unvote, unfavorite, etc. Obviously, handling of Undo has to be at least partially specific to the thing being undone, but they are all expressed using the same primitive.

arinlen 4y ago
> UNDO makes sense if the server is keeping a bag of responses. I disagree. Any UNDO action is just a DO action with a spcific set of commands executed in a specific order. If you use POST and PATCH and DELETE to apply actions, not only can you replay them but you can also trivially support a POST /resource/<resourceId>/undo. This is particularly relevant in systems that employ an event sourcing of some sort.

freedomben 4y ago

Yeah, it's gotta be a joke. The only one that actually sounds useful to me is HELP. I have to disagree with you on that one, a HELP that could explain the endpoint and verbs? that would be AWESOME. kind of like `kubectl explain`, which has been helpful to me on multiple occasions. Of course 99% of apps would not implement that, but frameworks could easily give you that for free as the dev, and reuse the declarative code that already exists in the router... There are already tools that generate swagger files and such, seems like it wouldn't be much harder to render a server response/document on demand. You could even serve a beautiful doc page viewable in a browser! The more I think on this, the more I like it.

Joker_vD 4y ago
That's pretty much just entrypoint for HATEOAS, isn't it?
hn_throwaway_99 4y ago
FWIW, this is a huge benefit of GraphQL. All GraphQL servers that publish their schemas can instantly have their schemas loaded with full documentation and an interactive execution environment with GraphQL Playground.
- capableweb 4y ago
  Is it really a distinct benefit though since something similar to that have been existing for a really long time before GraphQL already? From OpenAPI/Swagger all the way back to HATEOS/HAL and RDF, if not even earlier.
  - freedomben 4y ago
    I'm not generally a fan of graphql, but yes it's a remarkable feature. The other options (like swagger) take more effort and tend to not be maintained well. But even when they are, it's still not as developer friendly (to the client) as graphql.
  - eurasiantiger 4y ago
    It is a distinct benefit when your query playground is schema-aware and can suggest completions for types, fields and field (query) parameters, as well as validate everything pre-request.
  - hn_throwaway_99 4y ago
    I've worked with all of those options before I started working with GraphQL. The "out-of-the-box" support, especially the standardization that GraphQL enforces with its schema definition, is/was night-and-day compared to something like Swagger.
adeel_siddiqui 4y ago