What does HackerNews think of http-decision-diagram?

An activity diagram to describe the resolution of HTTP response status codes, given various headers.

Language: JavaScript

#13 in HTTP
Optimizing Images with the HTML picture Tag | Oct 2022
Expand Context ↕
I wish more people knew about this: https://github.com/for-GET/http-decision-diagram and https://github.com/for-GET/know-your-http-well
Show HN: Erlang REST framework | Nov 2017
Expand Context ↕
nothing "REST" about it. 100% HTTP

PS: if anyone is interested in a language-agnostic artifact like cowboy's or webmachine's, see https://github.com/for-GET/http-decision-diagram
Designing state machines | Jun 2017
FWIW there is a standard to describing (finite) state machines despite the RFC being expired https://tools.ietf.org/html/draft-bortzmeyer-language-state-...

I have used an "improved" version of it https://github.com/andreineculau/cosmogol-abnf when working on https://github.com/for-GET/http-decision-diagram

Next steps for Gmane | Sep 2016
Expand Context ↕
HTTP won out because it's the 'universal' protocol: you GET a resource, you say 'I prefer text/html but really anything is fine', the server puts bytes on the wire, it includes some metadata (headers, Content-Type), and then your user-agent interprets that Content-Type and displays the result. It's an extensibility advocate's dream. Using this and the jack-of-all-trades datatype HTML, we developed documents that link to other documents. When we were no longer okay with static pages, we hooked up programs that wrote HTML onto stdout and at the end of the day, everything just came across as a sequence of bytes. There's no formalized, official application-level logic to the HTTP state machine (although there are third-party attempts [1]).

Using these universal building blocks, we built applications where state transitions consists of GETs and POSTs. Eventually, when we wanted machine-structured data, we did XML-RPC, later codified into SOAP, before the backlash against hard-to-understand standards led to JSON being traded between server backends and client-side obfuscated, minified Javascript state machines.

Not enough people make new running-on-TCP or running-on-UDP protocols because new protocols are hard to design, they don't work with the one application where everyone spends 70+% of their time (the web browser), and they probably get blocked on a middlebox except if you use port 80 or 443 and fake being HTTP anyway. For all but very specialized use-cases, vomiting blobs of JSON (or if you want to feel extra good, some custom binary serialization format like protobuf or Thrift or Cap'nProto or MessagePack) across HTTP endpoints is pretty okay.

[1] https://github.com/for-GET/http-decision-diagram
Writing an editor in less than 1000 lines of code, just for fun | Jul 2016
Expand Context ↕
You're thinking of https://github.com/for-GET/http-decision-diagram
Choosing an HTTP Status Code | Dec 2015
Expand Context ↕
The more up to date version of this diagram is here:

https://github.com/for-GET/http-decision-diagram
Choosing an HTTP Status Code | Dec 2015
I seem to recall that this flow chart covered all the bases pretty thoroughly:

https://github.com/for-GET/http-decision-diagram

Choosing an HTTP Status Code | Dec 2015
The for get http repo already looks to provide a http status flow diagram at https://github.com/for-GET/http-decision-diagram.

Its a version 4 currently

Choosing an HTTP Status Code | Dec 2015
It's good to see more diagrams/flowcharts on the matter, but beyond that - for those that understand the power of abstraction between layers, but you think there should be a simple straightforward to spit out the correct http status code while you worry about the semantics alone: https://github.com/for-GET/http-decision-diagram

* an old PoC in NodeJS exists that reads the states/transitions from a JSON file and calls the correct callbacks in the correct order. Implement the callbacks (semantics) and you're done.

Disclaimer: I'm the author.

Why REST is not a silver bullet for service integration | Jan 2015
I believe at least some of the pain points of "modern REST" mentioned in the article would be eliminated by wider adoption of proper FSM-based REST implementations, e.g. [1] or [2] (the latter is a spec and not a concrete implementation). This way, REST becomes a "template" for an "autonomous agent"'s logic, kinda like our brains are a "templates" for our personalities. Adoption of such "template" helps to establish invariants, which are crucial for large systems.

[1] https://github.com/basho/webmachine

[2] https://github.com/for-GET/http-decision-diagram/

edit: formatting