• 报名通道已经关闭,但欢迎现场签到入场~

  • 当日参加活动的小伙伴请入群

  • 你来贡献题目,众筹来车票给你~ 然后就不要回去了🍻

  • 去掉了手机号,其他信息非必填。之前不够注意~

  • 之前项目就是 token 放 header,然后 https。

  • 👍

  • 我觉得这是两个问题。

    第一个是网络应用的风格有哪些(Network-based Architectural Styles),REST 是一种,还有 Data-flow Styles,Replication Styles,Hierarchical Styles etc,这个在 Roy 的论文第三章都有提到(英文版论文请点这里)。而 REST 是在考量了 性能(Performance),扩张性(Scalability),容易修改(Modifiability)etc 这些网络应用的关键要素后提出的解决方案(性质参考第二章)。

    第二个问题就是框架了,也就是 Rails。REST 首先只是指导原则,并没有提出任何实现的细节,而 Rails,或者其他的框架都是具体的实现,就是是尊重 REST 的原则。 REST 风格的特点在于:

    • Client-Server (目前普遍采用的结构方式,但是在2000年以前并不是这样,具体看论文)
    • Stateless(是不是很眼熟,其实就是HTTP协议,Roy  参与了 HTTP 的定稿)
    • Cache (使用缓存来优化用户访问体验)
    • Uniform Interface (统一的接口定义,也就是 HTTP Verbs)
    • Layered System ( 分层)
    • Code-On-Demand (客户端代码,也就是 js)

    所以 Rails  框架根据这些指导做出了具体的实现。对于开发者来说要做的,就剩下三个任务:

    •  定义资源(Resource)
    • 定义资源的表达方式(Representation, html, json, xml or custom format)
    • 定义资源的状态转换(也就是资源和资源之间的 links)

    符合了这样风格的框架之间没有本质的优劣区别,不同之处落在了语法上,本身语言的特性上,框架易用性(是否是 convention over configuration)等等。

    P.S. 论文发表的时间是 2000 年,那是在有了实验结果以后才敢的发表(治学严谨啊),真正提出这个风格的时间大概是 1996 年。那个时候互联网还在襁褓中,所以阅读论文的时候可以抛开 rails 或其他框架的具体实现细节,就当是读一份互联网应用风格发展的简史。

    上班前随意写了一些,希望有解答问题。

  • #2楼 @small_fish__

    • 套餐我都默默的选择最小套餐,先把应用跑起来是王道
    • beanstalk 的服务并不需要保存和使用 pem,通过 eb command line tools 完成
    • 防火墙基本没管,原因看第一条
    • 按照 Elastic Block Store 收钱,具体没关注是多少
  • 2011 年的文章, by stevek labnik,nobody-understands-rest-or-htt。 简言之所有的 custom actions 都是因为没有挖掘潜在的 resources。 不过在实际开发中的中小型项目,为了快速开发,真是 custom action 满天飞,尤其是 /items/search 这样的 api。

  • 书昨天寄出,今天已经收到。🐵犀利