I'm fond of data-URI's (MDN Link). 12 years ago I reappropriated a tool that stored a webpage with its related resources in a Microsoft specific format and rewrote it into something that would store it in normal HTML where the related resources were encoded in data URI's. Recently the topic came up again at a project I was working in, where microservices are still a thing. And while discussing it with colleagues it seemed as if knowledge about this quite useful URI-scheme wasn't on top of everyone else's mind. Instead, the original idea was, we could upload the resource to S3, pass the link, download the resource from S3 at the receiving end, and then have some policy that takes care of deleting it… nah…
This is the most simple data-URI:
data:,Hello%2C%20World%21
You [can open it in your browser](dat…
If you're into archival stuf, you've probably come across the concept of PIDs. PIDs help organisations attribute data to consistently identified objects. There are different PID-schemes. Books can be persistently be identified by their ISBN. In science, DOIs are popular to identify scientific articles. And there are plenty of other persistent identifiers.
What most of them share is the following: they need registration. And while that could be a good thing, I've seen well meant attempts at creating a PID where the central entity went rogue, links are dependent on some centralised resolver and it all falls apart.
When I was tasked to create a long lasting QR label the requirements were clear:
Web Services hebben we het over het gedeelte van het internet dat begrepen kan worden, in tegenstelling tot het gewone web van web sites, door computer systemen. Er zijn verschillende manieren hoe je computer A over het internet met computer B kunt laten praten, en de RESTful wijze is er daar 1 van. In het boek RESTful Web Services, geschreven door Leonard Richardson en Sam Ruby (ISBN nr.: (978) 0596529260), wordt deze wijze uitgebreid behandeld.
Ten opzichte van andere manieren van communiceren over het internet is dat het uit gaat van de eenvoud van het HTTP protocol, dit in tegenstelling tot b.v. SOAP en RPC. Hoewel ook deze technologiën uiteindelijk wel over het HTTP gaan hebben deze technologiën een geheel andere benadering in de wijze waarin informatie op gevraagd en gemanipuleerd kan worden. Deze benadering is resource oriented, i.p.v. activity oriented. In plaats van de actie die veelal centraal staat …
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .