A few of us (and probably a disproportionate number on this site as compared to the general public) undoubtedly download and archive interesting material for just that reason.
I wish there were a very good conversion utility to download sites and convert them to PDF, especially for Mac. If there is one, I don't know about it. I've resorted to either printing the "reader" version to PDF from Safari, or copying and pasting into a word processor.
Saving webpages to PDF is quite terrible, because it often breaks things into "pages" and you end up with blank headers and footers on each page breaking the flow. You also very often have things cut off from the right-hand side of the webpage.
You have these options:
- SiteSucker to preserve a perfect copy of the website, though I'd use a VPN, 1 or 2-sec delay, and spoof user agent
- Firefox with the SingleFile extension lets you save an HTML file that includes all resources, much better than the Save As option in Chrome/Firefox
Just a heads up, many (all?) of your comments (including this one) show as dead. I vouched for this one. Might want to contact a moderator or something.
>"Hey @PostThisTooFast, you seem to be shadowbanned based on two flagged comments when your account was new in 2015. Hey @dang, this account has made many good comments since then."
To anyone confused by this thread, look at the "showdead=[yes|no]" toggle in your HN preferences.
Yeah, it's pretty cool. I am tasked with developing a new API and communication method for a bunch of networked devices that run embedded Linux. Initially I focused on MQTT, but have since decided to define an API in OpenAPI and implement an HTTP/REST-style interface because that's well understood and easily supported by third parties, whose APIs we might want to integrate with or provide a translation layer for.
But the devices need to alert a controller application to status changes... which so far I supposed they would do by POSTing REST-style messages back to that application. Do people combine REST & MQTT?
I'm not a REST+MQTT expert, but some people do combine them, why not?
One of the project I was working on (IoT, smart home), the mobile app received the current status from the REST API, then subscribed to changes via MQTT. Having MQTT was great for live updates on the mobile app, and for communicating with the IoT devices. HTTP was great for integrations with Google Home, Alexa, and we could test it easily as there are many backend frameworks focusing on CRUD REST HTTP backend apps.
Of course, if you actually have a problem you want to solve, be sure the to do your own research, there are more than one way to skin a cat, and there are so many services and platforms that could be "good enough" for your use case.
Generally people choose MQTT because it is lightweight and very well tested. I personally use it because its light one source, scalable, and very flexible. Have also chosen to use CoAP rather than REST for ad hoc data requests because for constrained devices it is much lighter on bandwidth, simpler to use than typical REST over TCP+HTTP with which most people are familiar.
In IOT its hard to go past MQTT for the usual signals paired with CoAP for ad hoc. When I want to reduce dependencies or just being lazy even CoAP gets replaced with building a request/respond mechanism using a MQTT queue so a hub pubs a message to the devices command queue and device reads that queue and responds to it. How often device checks the command queue depends on whether or not device can run command queue monitoring asynchronously or must do a scheduled round-robin of the queues.
The Eclipse Paho libs have been great for me using across different OS and bare metal, Arduino, FreeRTOS.
One thing to note is that MQTT is session-oriented, so you have to send periodic pings to the server to keep your session active. Which is obviously a deviation from stateless REST.
The REST paper explicitly mentions that REST and HTTP only try to solve the common cases, and solve those well. If something is not covered well then you’re explicitly advised to leave it to another protocol. You could for example have a GET response that (due to HATEOAS) suggests a websocket url including a topic to subscribe to.
And people who prefer computers should be very, very happy about that; because touchscreens on computers are stupid.