有个梨UGlee
2020-01-13 00:00:00 发布
hierarchical resources。
++++
包括文件系统，xml文档，JSON对象，restful API，甚至document db等等，都是层级资源描述；层级资源描述非常常用，虽然不是万能的，比如我们需要更复杂的关系表述和查询时，可能需要诉诸真正的数据库。
但是很奇怪的是我们为什么要使用这么多种不同的方式。
文件系统的缺点是两个，第一它没法一次性读取一个subtree，比如Linux的proc/sysfs象注册表一样暴露了很多内核信息，但没法一下子读回来一个目录内的所有文件内容，也有可能在多次读取的过程中遇到内容变更，导致数据不一致。这是xml或者JSON这类文档结构的好处。
文件系统的第二个缺点是它是使用name value的，name相当于是一个identifier，一个目录内的文件不得出现相同的名字；这个设计粗看是OK的，但是有严重的隐患，就是这个identifier，是client提供的而不是server（kernel）提供的。你想一下就会发现这个设计和restful资源不同，restful资源的唯一ID是server端分配的。
实际上文件系统也有inode number可以作为唯一ID标识，但是这里有个很大的麻烦，Unix上文件的权限设计是基于path的，path包括hardlink和symbolic link，link可以表述一个引用关系，实际使用中相当灵活，能解决不少问题，以此来补足层级结构实际上是partition的问题。
Unix上的资源访问是沿着路径检查的，和link一样这个简单的设计也解决了很多实际问题，但是这个设计是Unix里唯一的（文件）资源访问时的基础权限设计，换言之，它没有基于inode number的资源访问方式，因为没有机制auth，而且由于link的存在，构建一个map来反向查找也不可能，一个资源可以有大量经过link的路径，其中一些可能是允许访问的，另一些则不可能。
所以这里拿restful对照的话就会发现，古老的Unix文件系统设计在把文件当作「共享」资源服务时有天生的弊端。
++++
xml和JSON用于解决另外一类问题，两者相比而言，xml更完备一些，它有更好的schema定义，节点有attribute；但JSON更加literal，象简洁的口语；document db很多的时候就像大量不规则xml或JSON资源的可查询版本。
++++
综合来说，我们发现在资源表述上存在这样一些问题。
这个层级是有刚性边界的，比如HTTP path其实也是hierarchy，只有不多的HTTP服务实现上允许更长的path访问到JSON对象的层级（即访问到内部去），这个刚性边界的存在其实并没有意义。
此其一。
其二，文件系统有相对路径的概念，多数操作系统都支持系统，甚至程序，有自己的namespace，例如Unix里著名的mount，挂载点的位置是程序自己定义的，程序可以根据需要构建自己的namespace，程序可以从一个path读取数据处理后保存到另一个path去。这个相当不错的特性，在xml/JSON流行的时代，竟然丢失了！换句话说，网络资源都只能基于绝对路径工作。如果操作系统设计成这样是要挨打的。
++++
这篇微博没有结论，只是抛出问题。
网络资源表述在允许大家瞎发明层级结构的资源表述，然后把简单的代码重写很多遍；就为了对付路径或者包含关系或者资源的namespace这么简单的问题。
Unix先驱们发明文件系统时的统一抽象和由此带来的代码精简和重用精神，都被丢弃了。
2020-01-13 00:00:00 发布
hierarchical resources。
++++
包括文件系统，xml文档，JSON对象，restful API，甚至document db等等，都是层级资源描述；层级资源描述非常常用，虽然不是万能的，比如我们需要更复杂的关系表述和查询时，可能需要诉诸真正的数据库。
但是很奇怪的是我们为什么要使用这么多种不同的方式。
文件系统的缺点是两个，第一它没法一次性读取一个subtree，比如Linux的proc/sysfs象注册表一样暴露了很多内核信息，但没法一下子读回来一个目录内的所有文件内容，也有可能在多次读取的过程中遇到内容变更，导致数据不一致。这是xml或者JSON这类文档结构的好处。
文件系统的第二个缺点是它是使用name value的，name相当于是一个identifier，一个目录内的文件不得出现相同的名字；这个设计粗看是OK的，但是有严重的隐患，就是这个identifier，是client提供的而不是server（kernel）提供的。你想一下就会发现这个设计和restful资源不同，restful资源的唯一ID是server端分配的。
实际上文件系统也有inode number可以作为唯一ID标识，但是这里有个很大的麻烦，Unix上文件的权限设计是基于path的，path包括hardlink和symbolic link，link可以表述一个引用关系，实际使用中相当灵活，能解决不少问题，以此来补足层级结构实际上是partition的问题。
Unix上的资源访问是沿着路径检查的，和link一样这个简单的设计也解决了很多实际问题，但是这个设计是Unix里唯一的（文件）资源访问时的基础权限设计，换言之，它没有基于inode number的资源访问方式，因为没有机制auth，而且由于link的存在，构建一个map来反向查找也不可能，一个资源可以有大量经过link的路径，其中一些可能是允许访问的，另一些则不可能。
所以这里拿restful对照的话就会发现，古老的Unix文件系统设计在把文件当作「共享」资源服务时有天生的弊端。
++++
xml和JSON用于解决另外一类问题，两者相比而言，xml更完备一些，它有更好的schema定义，节点有attribute；但JSON更加literal，象简洁的口语；document db很多的时候就像大量不规则xml或JSON资源的可查询版本。
++++
综合来说，我们发现在资源表述上存在这样一些问题。
这个层级是有刚性边界的，比如HTTP path其实也是hierarchy，只有不多的HTTP服务实现上允许更长的path访问到JSON对象的层级（即访问到内部去），这个刚性边界的存在其实并没有意义。
此其一。
其二，文件系统有相对路径的概念，多数操作系统都支持系统，甚至程序，有自己的namespace，例如Unix里著名的mount，挂载点的位置是程序自己定义的，程序可以根据需要构建自己的namespace，程序可以从一个path读取数据处理后保存到另一个path去。这个相当不错的特性，在xml/JSON流行的时代，竟然丢失了！换句话说，网络资源都只能基于绝对路径工作。如果操作系统设计成这样是要挨打的。
++++
这篇微博没有结论，只是抛出问题。
网络资源表述在允许大家瞎发明层级结构的资源表述，然后把简单的代码重写很多遍；就为了对付路径或者包含关系或者资源的namespace这么简单的问题。
Unix先驱们发明文件系统时的统一抽象和由此带来的代码精简和重用精神，都被丢弃了。