在这篇文章中，我想到了核心技术的重要性，以及"功能即服务"的出现可能仅仅是一个已经存在了一段时间的想法的下一个化身，真正简单的联合和丰富的网站摘要）以及作者应该如何在RSS提要中包含整个博客文章内容。在对话中，人们不禁要问，RSS是否还在被使用；尽管几年前卓越的RSS阅读器Google reader已经消失，但RSS依然存在，并为网络上的联合与共享提供了动力。（如果你想了解更多关于RSS，wap自助建站，它的历史和它与OData的关系，你可能想读一读"周一早晨的想法：OData"。
这让我想到RSS所依赖的协议-古老的超文本传输协议（HTTP）。HTTP已经存在很长时间了，就像电子邮件已经成为异步通信的一种通用机制一样，HTTP也是各种事物的通用机制。为什么？嗯，我认为一个原因是它美丽的简单。当HTTP第一次出现在现场时，我记得我为它感到高兴，也确实为它与电子邮件的相似之处感到高兴。
电子邮件和HTTP的美丽简洁
来自互联网工程任务组（IETF）的822号官方征求意见（RFC）文件描述了电子邮件的外观。邮件中有邮件头和邮件正文。标题是名称：值对，标题与正文之间用空行分隔。下面是一个简化的示例：
在RFC2616中描述的HTTP中，消息要么是请求，要么是响应，在这两种情况下，欧洲云服务器，结构都是相同的：头的形式是名称：值对，空行，然后是请求或响应的有效负载。下面是一个简化的HTTP请求示例（这个没有有效负载）和相应的HTTP响应：
请求：
响应：
所有这些不同示例的简单性和相似性有一个优点–它们遵循相同的模式，甚至共享一些头（如日期和内容类型），最重要的是，它们是人类可读的*.
HTML电子邮件的出现使这一点更具挑战性，并导致许多优秀的纯文本电子邮件客户端的死亡，如（我最喜欢的电子邮件客户端的所有时间）mutt，但这是另一个时代的故事。
有人试图改善今天的HTTP，你可以看到这些尝试以SPDY和HTTP/2.0的形式出现。当然，我们在服务器和客户端（浏览器）之间使用了web套接字和WS-protocol前缀……但最终，HTTP的核心仍然是强大和无处不在的。事实上，在我今年的一次SAP TechEd会议（LT106"了解整个SAP中开发人员的可用路径"）的拉斯维加斯和巴塞罗那版本中，我曾告诫与会者，无论走哪条路，都要学习核心技术。我认为每个人都应该学习的核心技术之一是HTTP。
Probot和Webhooks
本周末我研究的另一项技术是我上周参加DevRelCon 2018 London的结果，在那里，除其他外，我了解了GitHub必须提供的各种工具，这些工具超出了我所认为的核心（通过基于分布式源代码控制系统git的存储库和项目管理的社会化编码）。其中一个工具是Probot，云服务器 免费，它允许您使用应用程序来扩展GitHub中管理的进程。
Probot字符
应用程序可以预先构建，也可以自己创建。从本质上讲，Probot是一个建立在两个基本机制之上的层——webhooks和GitHub事件API，使这些应用程序的构建更加容易。它们是什么？把webhooks看作是一种基于架构模式的HTTP使用。webhooks的概念已经有十多年的历史了，云免费，最早是由Jeff Lindsay发明和推广的，参见他2007年的文章"webhooks彻底改变Web"。他将它们描述为"用httppost生成的用户定义回调"*，当时webhooks的一个核心用例是解决轮询的挑战——一个软件对另一个软件的重复请求，一遍又一遍地问："有什么新的吗？""你完成了吗？""你有什么要给我的吗？"以及类似的要求。投票模式通常是最容易考虑和实现的，但它相当浪费和低效。
*有趣的是，Jeff将webhooks比作pingbacks，我在上周的文章中写道："周一早晨的想法：关于开始写博客"。
早在2007年Jeff描述这种架构模式时，我们立即看到了通过HTTP松散连接的事件驱动服务网络的可能性。在那个时候，HTTP是应用程序间通信的通用语言。看看Probot构建的另一半——GitHub的事件API。想在源代码更新时自动执行一些检查吗？想在向特定存储库发出请求时触发组织中的流程吗？注册一个回调，在这些事件发生时执行。执行的形式只是一些代码，在某个地方，它响应一个HTTP请求，一个由引发事件的系统发出的请求（在本例中是GitHub），并将HTTP POST发送到您注册的回调端点。同样，在这里，了解HTTP协议以及理解HTTP服务器框架如何工作的本质是一项基本技能，在我看来*.
*促使我最初为ABAP堆栈创建备用调度层（ADL）的一个想法是HTTP服务器框架之间的可爱相似性而且很小，跨越不同的语言和环境。请参阅"ICF的新REST处理程序/调度器"和Nigel James的演示文稿"备用调度器层概述"，了解一些背景知识。
功能即服务（FaaS）
