Hacker News Reader

Comment by knome | Hacker News Reader

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

View on HN

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.

That's pretty much just entrypoint for HATEOAS, isn't it?

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.

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.

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.

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.

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.

Isn't there already the OPTIONS verb which does the same thing as a possible HELP method?

>The HTTP OPTIONS method requests permitted communication options for a given URL or server. A client can specify a URL with this method, or an asterisk (*) to refer to the entire server.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/OP...

Yes, good point, OPTIONS would probably cover this use case. Anybody know of a framework (such as rails, phoenix, laravel, etc) that offers that? would be super interesting

> The only one that actually sounds useful to me is HELP.

And we already have OPTIONS for that.

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.

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

Reply on news.ycombinator.com