现在学什么编程语言最有前途？这些编程语言程序员工资高_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
现在学什么编程语言最有前途？这些编程语言程序员工资高
0|0|暂无简介|
北大青鸟佳音旗舰校区是北大青鸟北京旗舰校...|
总评分0.0|
阅读已结束，如果下载本文需要使用0下载券
想免费下载更多文档？
你可能喜欢通过安全审计系统实现企业数据双保险
通过SIEM系统基础架构扩展了系统保障和数据保险的附加值
高效 严谨 进取 创新
博创华宇 IT人才外包服务
对外涉及对欧美java软件外包、对日软件外包、对日BPO、金融保险、电信、电子政务等主要业务领域。
博创华宇联合Splunk
企业安全信息和事件管理系统咨询
提前确认需要哪些系统日志文件用于监视是非常关键的。有些公司要求大量的以不同方式收集和处理数据的日志。在SIEM系统能够提供报告之前，各种日志都需要标准化，其目的是保持数据的一致性。
　　程序员当初在选择一门编程语言时，会思考很多因素，比如：薪资、这门语言是否吃香等。还有一些初级程序员会思考，我该学习哪门语言才能有利于我的职业生涯规划与成长，Java还是ReactJS或者是Android亦或者是NodeJS…
　　在开始之前，请大家思考一下，影响薪资的客观因素有哪些？比如经验、地理位置等。与此同时，在讨论薪水的时候，你或多或少地有一些开发经验。下面的数据分别来自2016 StackOverflow开发者调查和YouWorth。
　　与此同时，附上一张2016年TIOBE 7月份的编程语言排行榜：
　　了解完最新的编程语言排行以后，下面来看看各门编程语言的薪资状况：
　　开发者使用Ruby最大的优势就是敏捷开发，它具有可扩展性和非常活跃庞大的社区。目前，它正被一些流行的互联网公司采用，如Twitter、Github等。
　　Ruby平均工资US(每年):
　　YouWorth——$103,000
　　StackOverFlow——$ 95,000
　　JavaScript
　　JavaScript编程语言普遍用于前端开发，它几乎可以应用于任何应用程序，包括系统级应用程序。而且，目前一些流行的框架，大部分是基于JS的，比如React.js、Angular.js、Node.js等。
　　JavaScript平均工资US(每年):
　　YouWorth——$90,000
　　StackOverFlow——$95,000
　　Swift/Obj-C
　　Swift面世只有2年的时间，却深受开发者们喜爱。开发者最好同时学习Swift和Objective-C这两门语言，这样更有利于在iOS平台上的发展。
　　Swift平均工资US(每年):
　　YouWorth——$96,000
　　StackOverFlow——$95,000
　　Obj-C平均工资US(每年)：
　　YouWorth——$105,000
　　StackOverFlow——$100,000
　　C语言面世已有50年的时间，但却愈发强劲。开发者可以使用C语言创建复杂的图形应用程序和操作系统内核。
　　C平均工资US(每年)：
　　YouWorth——$103,000
　　StackOverFlow——$100,000
　　Java可以用来开发任何类型的应用程序，事实证明，大公司一直都比较偏爱用Java来构建企业级软件。
　　Java平均工资US(每年)：
　　YouWorth——$94,000
　　StackOverFlow——$88,000
　　Python
　　Python深受欢迎主要得益于它在多元项目中所表现出的可读性和可用性。它主要用于科研项目，也适用于Web开发和应用程序开发。近年来，Python随着工资的高涨，需求量也不断增加。
　　Python平均工资US(每年)：
　　YouWorth——$103,000
　　StackOverFlow——$100,000
　　PHP是一门后端服务器编程语言，目前有超过80%的网站是使用它构建的。最新推出的PHP 7进行了很大的性能提升与优化。
　　PHP平均工资US(每年)：
　　YouWorth——$87,000
　　StackOverFlow——$75,000
　　C++经久不衰的最大因素是它的执行速度。Facebook公司使用它来处理每秒数百万的请求，并且具备无与伦比的可伸缩性和可靠性。
　　C++平均工资US(每年)：
　　YouWorth——$99,000
　　StackOverFlow——$100,000
　　C#可用来开发游戏、移动应用程序，并且API的提升也巩固了其市场地位。
　　C#平均工资US(每年)：
　　YouWorth——$107,000
　　StackOverFlow——$95,000
　　VisualBasic .NET
　　VisualBasic .NET取代了Visual basic语言，主要用于开发前端应用程序。
　　.NET平均工资US(每年)：
　　YouWorth——$97,000
　　StackOverFlow——无数据
　　SQL是一门数据库开发语言，用于数据检索、存储等数据操作。它并未因为NoSQL和MongoDB的面世而降低其薪资水平。
　　SQL平均工资US(每年)：
　　YouWorth——$91,000
　　StackOverFlow——$95,000
　　开发者到底应该选择哪门语言？
　　正如你所看到的，任何一门语言，想要获得较高的报酬，都必须要有一定的开发经验。其次，选择一门语言最大的因素，除了薪资的诱惑外，个人兴趣和职业成长才是最重要的因素。
　　在IT行业，拥有多门技术或者成为全栈工程师已成为一门趋势，在StackOverFlow调查过程中发现，大多数开发者都会同时使用多门语言，如下图所示：
　　20多年来，java平台以其移动性、安全性和开放性受到追捧的同时，驱动了java从业人员的激增，根据IDC的统计数字，在所有软件开发类人才的需求中，对java工程师的需求达到全部需求量的60%~70%。2016年收入最高的5个编程语言 - 知乎专栏
{"debug":false,"apiRoot":"","paySDK":"/api/js","wechatConfigAPI":"/api/wechat/jssdkconfig","name":"production","instance":"column","tokens":{"X-XSRF-TOKEN":null,"X-UDID":null,"Authorization":"oauth c3cef7c66aa9e6a1e3160e20"}}
{"database":{"Post":{"":{"title":"2016年收入最高的5个编程语言","author":"amin706","content":"电子书网站Packt公布了其2016年技术提高报告。它提供的统计数据基于超过11,000名IT专业人士参与的关于2016年收入最高的编程语言的调研。它同时还介绍了流行的web框架和主题。高效的是基于IT的企业结构的中坚力量。企业雇用擅长于不同编程语言的人，并支付他们薪水，这样人员才不会被竞争对手撬走。现在有许许多多的编程语言，数以千计的开发人员在用这些编程语言工作。但是，在薪水方面，学习有些编程语言的人超过学习其他语言的人。Packt，一个电子书网站，发布了2016年技术提高的调查报告，涉及来自世界各地的11500名开发人员。该报告描述了领先的IT专业人员和开发人员所使用的编程语言的趋势。在受访者中，来自美国的人数最多，其次是英国。最流行的编程语言是：JavaScriptPythonJavaCSQL榜首是客户端脚本语言JavaScript。之所以对JavaScript的需求会升级，是因为越来越多的业务应用被转移到web浏览器。Python是一种通用语言，它可以用于从渗透测试到web开发。Python被广泛应用于各种组织，如D-LINK，惠普，飞利浦等。而既老旧又年轻的C语言也在名单中。C语言主要用于年轻的程序员在学校上手编码的时候。所以，很明显，在企业部门的话C语言专家可能得不到太高的薪水。然而，这些语言从财务角度来看都不是最好的。尽管它们很成功，但是开发人员并不能从这些语言上赚到最高的薪水。更赚钱的编程语言都并不大受欢迎。平均年薪薪酬最高的语言是：Bash——$ 100,000Perl——$ 95,000Scala——$ 90,000SQL——$ 62,000Delphi——$ 60,000专家程序员使用诸如bash和Perl语言。因此，当决定职位薪资结构的时候，这些语言更受企业喜欢。谷歌的Go（$ 50,000）语言俨然已经获得了关注，比更受欢迎的用于为苹果生态系统编码app的Swift表现更佳。Golang被设计得更让C语言老将喜欢，其代码一直以来保持着可读性和简洁。Golang被设计得更让C语言老将喜欢，其代码一直以来保持着可读性和简洁。它被接受主要是因为速度，快速的编码会话非常便捷。软件工程师以及应用软件开发是这种语言两个选择最多的工作。选择后端web开发的也相当多。流行的web开发框架：web框架中，AngularJS，是图表的佼佼者。然而，相当大百分比的开发人员已经开始或计划转移到几个月前发布的AngularJS 2。那些不盯着AngularJS 2的准备迎接更新的Facebook造的ReactJS。热门研究主题：除了编程语言和框架这些东西之外，调查也提及了开发者社区中感兴趣的流行领域。机器学习和大数据自去年以来一直是IT行业的热门话题。我们最近看到基于IBM Watson的机器学习如何想出对一种罕见的。详细信息请阅读2016年技能提升。有什么补充，欢迎告诉我们。翻译作者： – 小峰","updated":"T13:02:19.000Z","canComment":false,"commentPermission":"anyone","commentCount":18,"collapsedCount":0,"likeCount":96,"state":"published","isLiked":false,"slug":"","isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-38534faa05acaf1531c6_r.jpg","links":{"comments":"/api/posts//comments"},"reviewers":[],"topics":[{"url":"/topic/","id":"","name":"编程语言"},{"url":"/topic/","id":"","name":"开发者"},{"url":"/topic/","id":"","name":"程序员"}],"adminClosedComment":false,"titleImageSize":{"width":750,"height":340},"href":"/api/posts/","excerptTitle":"","column":{"slug":"lishichao","name":"互联网笔记"},"tipjarState":"inactivated","annotationAction":[],"sourceUrl":"","pageCommentsCount":18,"snapshotUrl":"","publishedTime":"T21:02:19+08:00","url":"/p/","lastestLikers":[{"profileUrl":"/people/wo-jiao-an-65","bio":"","hash":"aaac9de6eec","uid":042200,"isOrg":false,"description":"","isOrgWhiteList":false,"slug":"wo-jiao-an-65","avatar":{"id":"f2e3dfb38d407dac93c5cda9d30052fc","template":"/{id}_{size}.jpg"},"name":"我叫安"},{"profileUrl":"/people/yanis-ding","bio":"机械小民工","hash":"d744ff6db6595ac8bbbc14","uid":16,"isOrg":false,"description":"","isOrgWhiteList":false,"slug":"yanis-ding","avatar":{"id":"d20bbb93cdece0dbf00162","template":"/{id}_{size}.jpg"},"name":"Yanis Ding"},{"profileUrl":"/people/bin-lin-64","bio":"心无长夜亦无蛮荒","hash":"4a112e7f3f5c077c6e563b99b0fa1c51","uid":375500,"isOrg":false,"description":"","isOrgWhiteList":false,"slug":"bin-lin-64","avatar":{"id":"51dcca1fcc2306cadf2e3","template":"/{id}_{size}.jpg"},"name":"宾凛"},{"profileUrl":"/people/yes-i-can-93","bio":"用一句话来描述我自己是远远不够的","hash":"548f7ff555aed4a3b36530d32aeb9f34","uid":40,"isOrg":false,"description":"好好学习敲代码等我厉害了就答题","isOrgWhiteList":false,"slug":"yes-i-can-93","avatar":{"id":"v2-415aaadfdf94e","template":"/{id}_{size}.jpg"},"name":"Withfilling"},{"profileUrl":"/people/liu-quan-59","bio":"what's the next?next is web,web is here,web includes all","hash":"ca0cce3a401eae854f416ebc","uid":004400,"isOrg":false,"description":"前端开发 webAPP","isOrgWhiteList":false,"slug":"liu-quan-59","avatar":{"id":"v2-bfb946ec289","template":"/{id}_{size}.jpg"},"name":"刘全"}],"summary":"电子书网站Packt公布了其2016年技术提高报告。它提供的统计数据基于超过11,000名IT专业人士参与的关于2016年收入最高的编程语言的调研。它同时还介绍了流行的web框架和主题。高效的是基于IT的企业结构的中坚力量。企业雇用擅长于不同编程语言的人，并…","reviewingCommentsCount":0,"meta":{"previous":{"isTitleImageFullScreen":false,"rating":"none","titleImage":"/v2-eebc28c60fe477efccf7f2_r.jpg","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"Web 开发"},{"url":"/topic/","id":"","name":"开放 API"},{"url":"/topic/","id":"","name":"API"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"profileUrl":"/people/amin706","bio":"有情怀→渴望做出一款颠覆性App的代码工作者","hash":"fd983d762fb8","uid":528000,"isOrg":false,"description":"
奇点日报创始人，追求产品交互和设计的产品经理一枚
高逼格程序员技术分享平台 → \n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光
邮箱 → ","isOrgWhiteList":false,"slug":"amin706","avatar":{"id":"v2-a5db75ec863beb","template":"/{id}_{size}.jpg"},"name":"Larry"},"column":{"slug":"lishichao","name":"互联网笔记"},"content":"原文链接：译文链接：本文译者：张卫滨在Web API领域出现了一种很有意思的新趋势，那就是各种工程师和公司都在致力于为每个用户的特定需求编写专有的API。API实现理想化的设计遥遥无期，我们可能需要对其进行对应优化。一个API，应该是多个门面（Facade）吗？前言假设你的系统不仅要为iOS暴露API、为Android暴露API、为Web站点暴露API、为AngularJS应用前端暴露API，还要为各种机顶盒以及乱七八糟的移动平台或使用你API的第三方公司都暴露各自的API，在API实现理想化的设计之前，现实就会给我们重重一击，因为各种API消费者会有不同且固守的关注点。这样的话，我们可能需要对API进行对应的优化。体验式API在InfoQ上，Jér?me Louvel（Restlet的联合创立者和首席geek）曾经采访过Daniel Jacobson（Netflix公司edge工程团队的副主席），他们讨论了Netflix的体验式API（experience API）和临时API（ephemeral API）。Daniel的团队负责处理全球范围内所有的注册请求以及在各种设备上查找和回放视频的流量。借助体验式API的理念，Netflix创建了特殊的API，从而为给定的请求终端产生优化后的响应。通过临时API，Netflix的工程师会迭代式地转换和演化这些体验式API。体验式API的目标在于解决Netflix所面临的问题，那就是要将它的平台扩展至六千万用户以及数十个具有不同特性的设备。通过这样的专有API，Netflix能够让用户在各种设备上都获得最好的用户体验，并且根据设备的屏幕大小优化带宽，从而实现更少的延迟和数据量消耗。这样的话，能够让Netflix的工程师进展迅速并且独立于核心的后端团队，实现了隔离，他们具有自己的版本模式，独立组织自己的部署工作。在Netflix，有专门的团队负责这些体验式API，并不是由核心的API团队来负责每个客户端所衍生出的API。其实，并没有太多的公司具有Netflix这样的扩展性，Netflix为所有的API消费者均构建了专有的API，但是这并不意味着在你的环境中采取这种做法也是有效的。对于小型的组织，维护和演化太多的API前端可能并不是高效的做法，甚至是一种反模式，因为这种做法的成本会很高。Netflix必须要构建一个专门的API平台来支持这种方式。微服务架构目前的趋势是向基于微服务的架构迁移，API网关或API门面（facade）得到了复苏。架构会分散为多个小的服务，我们需要有前置的服务（front-facing service），它们会负责为用户暴露API。我们可以有很多微服务，因此也可以有多个针对用户的门面，这一点丝毫不足为奇。网关或门面能够让用户只进行一次调用，而不必要求用户多次调用底层的微服务。这会让API消费者的工作更加简单，并且有助于实现更加智能的网关或门面，它能够充分利用缓存（因为多次调用依然还有必要），应用安全功能（认证、授权）或实现特定的规则（速度限制、IP过滤）。API提供者能够控制消费者如何使用它们的API。网关（不管是来自供应商的还是像Netflix这样自建的）还会带来一定的附加价值，如边缘服务（edge service，公司中位于DMZ的API基础设施，能够以非常新颖和有趣的方式来使用，比如Netflix使用Zuul实现多个区的弹性）、流水线处理（pipelining）或过滤器链（帮助抽取横切性的关注点并实现企业范围内的模式）。服务于前端的后端Sam Newman在一篇文章中，研究了这种消费者专用API的方式，并将其称为“服务于前端的后端（Backends for Frontends，BfF）”模式。这种模式不会为所有的客户端创建通用的API，我们可以拥有多个BfF：一个用于Web前端、一个用于移动客户端（甚至一个用于iOS，另一个用于Android）等等。SoundCloud采用了BfF模式，具有针对iOS平台、Android平台、Web站点以及嵌入式Web的API前端。与在Netflix的场景类似，如果有专门的团队负责这些前端的话，这种技术能够达到最佳的效果。如果你只有一个团队负责后端及其API的话，那么最好不要用大量不同消费者的API变种来加重他们的负担。回到微服务方面，BfF对于迁移也是很有意义的：当从单体架构迁移至微服务时，某个BfF可以调用单体应用的功能，而其他的BfF则可以调用新的微服务，请遵循Strangler模式，按照这种模式，我们可以渐进式从遗留代码转移到新的演进方案上。单体应用是非常复杂的，很容易积累技术债，会同时混合太多的关注因素，而微服务能够让我们每次只聚焦一个特定的关注点。但是，微服务架构也有它的不足之处。我们需要对其进行运维，它们之间需要协作，它们可能会按照与大型单体应用不同的节奏进行演化。在这样一个分布式系统中，维护所有服务之间的一致性并不简单。众多微服务之间的通信可能会引入额外的等待时间，这是服务通信的延迟所造成的。微服务的数据副本和反规范化（denormalization）也会带来一定的影响，它们可能会使数据的管理和一致性复杂化。微服务并不是免费的午餐，你可以阅读Vijay Alagarasan的文章了解微服务反模式的更多信息以及Tareq Abedrabbo所撰写的“微服务的七宗罪”。采用体验式API或BfF的决定性因素可以归结为它们是否有专门的团队来维护。如果你们是很小的组织，只有一个团队来负责后端以及面向前端或Web的API，那么维护这么多的变种将会更加复杂（设想一下它们的维护成本），但是如果你们的组织足够大，那么多个团队能够更加容易地承担这些前端API的任务，并按照他们自己的节奏来演化这些API。API作为团队沟通的模式尽管公司是以团队的形式来组织的，但是我看到在越来越多的场景下，开发人员会被分为前端开发人员（Web或移动）以及后端开发人员，其中后端开发者会负责实现Web或移动设备所需的API。Web API成为了项目交付的中心点：API是一种契约，将不同的团队关联了起来，能够让他们高效协作。如果我们开发的API要给别人使用的话，很重要的一点就是不要破坏这种契约。通常，有些框架和工具能够让我们根据代码库生成API定义——例如，通过注解驱动的方式，在端点、查询参数等内容上添加注解。但有时候，即便你自己的测试用例依然能够通过，很小的代码重构也可能会破坏契约。你的代码库没有问题，但重构可能会破坏API消费者的代码。为了更加高效的协作，可以考虑采用API契约优先的方式，确保你的实现依然能够遵循共享的协议：API定义。目前，有不少可用和流行的API定义语言，如Swagger（Open API specification）、RAML或API Blueprint。你可以选择一个最适合你的。采用API定义的方式有多项优势。首先，因为我们的实现需要遵循API定义，所以兼容性就更不容易遭到破坏了。其次，API定义对工具化非常有利。通过API定义，我们可以生成客户端SDK，这样的话API的消费者就可以将其集成到他们的项目中，实现对API的调用，甚至可以作为skeleton，用来生成服务的初始实现。我们还可以创建API的mock，这样在底层API构建的时候，开发可以调用这些mock，从而避免协调API生产者和消费者之间不同的开发周期。每个团队都可以按照自己的节奏开展工作！但是，它的好处并不局限于代码和兼容性，还涉及到文档。API定义语言还会帮助我们对API实现文档化，它们会生成很漂亮的文档，展现了各种端点、查询参数等等，并且（有时）还会提供可交互的控制台，通过它，我们可以很容易地发起对API的调用。为不同的消费者提供不同的负载采用API契约优先的方式当然会有所帮助，并且会提供很多的收益，但是如果不同的客户端有不同的API需求的话，该怎么办呢？具体来讲，如果我们无法奢侈到有专门的团队来负责不同的API门面的话，那么该如何让API满足所有API消费者的需求呢？在InfoQ最近的一篇文章中，Jean-Jacques Dubray阐述了他为什么 停止使用MVC框架。在这篇文章的引言中，他阐述了移动或前端开发人员如何频繁地要求适合于他们UI需求的API，而不管底层业务理念的数据模型是什么。Dubray所描述的状态-行为-模型（SAM）模式能够很好地支持BfF方式。SAM是一个崭新的、反应型函数式的模式，它清晰地将业务逻辑与显示效果分开，进而简化了前端的架构，尤其是将后端API与视图进行了解耦。因为state和model与action和view进行了分离，所以action能够专门服务于给定的前端或根本不进行展现：这取决于你会将光标置于什么位置。我们还可以从中心后端或它们的门面中生成状态表述或视图。Web站点或单页应用可能需要展现产品的详细视图并且还要包含它的评论，但是移动设备则很可能只展现产品的详情和它的评分，并且允许移动用户在点击的时候再去加载评论。根据UI的不同，流程、可用的行为、详情等级以及查询到的实体可能都会有所差异。通常，在移动设备上，我们都希望减少API调用获取数据的次数，这是因为连接性和带宽的限制，我们希望返回的负载恰好只包含所需的内容，没有额外的信息。但是，这一点对于Web前端来说就没有那么重要，通过异步调用的方式，我们完全可以按照懒加载的方式加载更多的内容和资源。不管是在哪种场景下，API显然都需要快速响应，并具有很好的服务等级协议。但是，当我们要为不同的消费者提供多个自定义的API时，这方面有什么可选方案吗？特定端点、查询参数和字段过滤一种基本的方式就是提供不同的端点（/api/mobile/movie与/api/web/movie），甚至是更为简单的查询参数（/api/movie?format=full或/api/movie?format=mobile），不过我们可能还有更为优雅的方案。类似于查询参数，我们的API还可以让用户决定想要哪些字段，从而自定义返回的负载，比如：/api/movie?fields=title,kind,rating或/api/movie?exclude=actors。通过使用字段过滤的方式，我们还可以确定是否要在响应中包含相关的资源：/api/movie?includes=actors.name。自定义MIME媒体类型作为API的实现者，我们还有其他的可选方案。我们可以根本不提供任何的自定义的功能！消费者要么接受我们提供的API，要么将API包装到他们自己的门面中，在这个门面中，他们可以构建想要的自定义功能。因为我们都是非常友善的人，所以会给他们提供多个profile：在媒体类型方面，我们可以发挥创造性，根据消费者所请求的媒体类型不同，返回更加精简或更加丰富的负载。例如，如果你看一下GitHub API （）的话，可能会注意到这样的类型：application/vnd.github.v3.full+json通过使用“full” profile，API会提供完整的负载和相关的实体，你还可以使用“mobile”或“minimal”变种的profile。API消费者在发起调用时，就可以请求最适合其使用场景的媒体类型。Prefer头信息Irakli Nadareishvili曾经写过一篇文章，介绍了API中客户端优化的资源表述，提到了一个鲜为人知的头信息域：Prefer头信息（RFC 7240）。与自定义媒体类型类似，客户端可以使用Prefer头信息请求特定的profile：使用Prefer: return=mobile能够让API响应自定义的负载并且会带上Preference-Applied: return=mobile的头信息。注意的是，当使用Prefer头信息的时候，需要对应地使用Vary头信息。作为API开发人员，如果我们要负责确定支持哪种类型的负载，那么你可能会喜欢自定义媒体类型、Prefer头信息或专门的端点。如果你想要客户端能够更加灵活地确定要检索哪些字段或关联关系的话，那么你可能会更中意字段过滤或查询参数的方案。GraphQL与其React视图框架一起，Facebook为开发人员引入了GraphQL。在这里，消费者能够完全控制会接受到什么样的负载结果，包括字段及关联关系。消费者在发起请求时，指定了返回的负载应该是什么样子的：{\n
user(id: 3500401) {\n
isViewerFriend,\n
profilePicture(size: 50)
}\n}\nAPI所响应的负载应该会像如下所示：{\n
\"user\" : {\n
\"id\": 3500401,\n
\"name\": \"Jing Chen\",\n
\"isViewerFriend\": true,\n
\"profilePicture\": {\n
\"uri\": \"http://someurl.cdn/pic.jpg\",\n
\"width\": 50,\n
\"height\": 50\n
}\n}\nGraphQL会作为一个查询，同时还会作为回应该请求的描述。GraphQL让API的消费者能够完全控制返回的内容，提供了最高级别的灵活性。在规范方面，还有一种类似的方式，那就是OData，它能够让我们通过$select、$expand和$value参数来自定义负载。但是OData有点落伍，处在被抛弃的边缘，前段时间Netflix和eBay已经宣布不再支持OData，而其他的参与者，如微软和SalesForce对它依然提供支持。超媒体API最后一个要讨论的可选方案就是超媒体API。当提到超媒体API的时候，你通常会想到那些额外的超链接会让响应变得凌乱，它们可能会让负载的大小成倍增加。对于移动设备来说，负载的大小和调用的次数确实值得关注。尽管如此，非常重要的一点在于，我们要通过HATEOAS（超媒体作为应用状态引擎）来思考超媒体，它是一个经常被忽视的REAT API核心原则。它与API所提供的功能有关。消费者可以访问相关的资源，但是这些超媒体关系所提供的链接也可以作为不同的可选profile，比如：{\n
\"_links\": {\n
\"self\": { \"href\": \"/movie/123\" },\n
\"mobile\": { \"href\": \"/m/movie/123\" },\n
}\n}\n另外，有些超媒体方式能够完全接受嵌入式关联实体的理念。Hydra、HAL和SIREN提供了嵌入子实体的功能，所以我们在获取一部电影的信息的时候，也能以嵌入式列表的形式列出它的所有演员。在一篇关于如何选择超媒体格式的文章中，Kevin Sookocheff给出了一个样例，展示了如何访问“玩家的朋友列表”，在这个资源访问中，嵌入了这些好友的实际表述而不仅仅是这些资源的链接，因此能够减少对每个好友资源的访问：{\n
\"_links\": {\n
\"self\": { \"href\": \n
\"/player//friends\" \n
\"size\": \"2\",\n
\"_embedded\": { \n
\"player\": [\n
\"_links\": { \n
\"self\": { \"href\":\n
\"/player/\" },\n
\"friends\": { \"href\": \n
\"/player//friends\" }\n
\"playerId\": \"\",\n
\"name\": \"Sheldon Dong\"\n
\"_links\": { \n
\"self\": { \"href\": \n
\"/player/\" },\n
\"friends\": { \"href\": \n
\"/player//friends\" }\n
\"playerId\": \"\",\n
\"name\": \"Martin Liu\"\n
}\n}\n小结Web API所面临的消费者种类在持续增加，他们有着不同的需求。微服务架构会鼓励我们针对这些需求部署细粒度的API门面（也就是所谓了体验式API或BfF模式），但是如果你要满足太多不同消费者的需求的话，这可能会成为一种反模式，如果你只有一个很小的团队来应对所有前端的话，那么这种问题会更加严重。一定要进行必要的权衡！在准备采用某种方式之前，你需要学习可选方案的成本并考虑你是否能够支持这些方案。创建API的不同变种是有成本的，对于实现API的人和消费API的人来说均是如此，这取决于所采用的策略。此外，在发布API给消费者之后，你可能需要重新思考和重构这个API，因为在设计阶段，你可能没有充分考虑这些特定的设备或客户需求。如果你有专门的团队来负责这些API门面，那么这是一种可行的方案。如果你没有这么奢侈的团队的话，有一些其他的方式来为消费者提供自定义负载，而且能够避免引入复杂性，这包括一些简单的技巧，如字段过滤或Prefer头信息，也包括全面的解决方案，如自定义媒体类型或GraphQL这样的规范。但是，我们也不一定非得这样大动干戈，可以采用一种中间方案：一个主要的、完整的API，再加上一个或两个针对移动设备的变种，这样的话，很可能就已经满足了所有消费者的需求。再考虑增加一些字段过滤功能，这样每个人都会对你的API表示满意！原文：","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T20:50:20+08:00","url":"/p/","title":"Web API开发现状：一个API，多个门面，合理不？","summary":"原文链接：译文链接：本文译者：张卫滨 在Web API领域出现了一种很有意思的新趋势，那就是各种工程师和公司都在致力于为每个用户的特定需求编写专有的API。API实现理想化的设计遥遥无期…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0},"next":{"isTitleImageFullScreen":true,"rating":"none","titleImage":"/v2-fad_r.jpg","links":{"comments":"/api/posts//comments"},"topics":[{"url":"/topic/","id":"","name":"Java"},{"url":"/topic/","id":"","name":"Java 编程"},{"url":"/topic/","id":"","name":"书单"}],"adminClosedComment":false,"href":"/api/posts/","excerptTitle":"","author":{"profileUrl":"/people/amin706","bio":"有情怀→渴望做出一款颠覆性App的代码工作者","hash":"fd983d762fb8","uid":528000,"isOrg":false,"description":"
奇点日报创始人，追求产品交互和设计的产品经理一枚
高逼格程序员技术分享平台 → \n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光
邮箱 → ","isOrgWhiteList":false,"slug":"amin706","avatar":{"id":"v2-a5db75ec863beb","template":"/{id}_{size}.jpg"},"name":"Larry"},"column":{"slug":"lishichao","name":"互联网笔记"},"content":"作者：calvin本书架主要针对Java后端开发与架构。更新记录：4.0版把第五部份－具体技术的书整块拿掉了。《TCP/IP详解 卷1:协议》出到了第二版，增加《SRE：Google运维解密》，《Java8 实战》。更偏爱那些能用简短流畅的话，把少壮不努力的程序员所需的基础补回来的薄书，而有些教课书可能很著名，但干涩枯燥，喋喋不休的把你带回到大学课堂上昏昏欲睡，不录。1. 操作系统与网络的书Robert Love用最薄的篇幅，顺畅的文字将Linux内核主要的算法讲清楚了，，之类厚厚的全是代码，不是专门的内核程序员看这本足够了。继续是Robert Love，比起APUE也是以薄见长，专门针对重要的系统调用讲解。操作系统的性能调优、监控、工具和方法论，看这本就够了，已经足够厚，可能是书单里最厚的一本。这么多年过去了，TCP的书好像主要还是只有这一本，有点旧了，看了也还是半懂不懂的。后人在2011年写了第二版。多少人，是看了这两本轻松又实战的书，才真正理解TCP的细节。PS:和，APUE和UNP更多作为一本超厚工具书存在。，扯的都是闲篇，厚厚的一本其实略读一下就行。 如果看LKD未尽兴，可以回头看看这本基础概念，感觉比那本枯燥的(恐龙书)读起来舒服。 前面wireshark书作者的推荐，网上有英文免费版，然后有中文版的和，但可能那么多章节那么厚你只关心TCP和HTTP两部分。，同样是自己从厚厚的目录里挑选感兴趣的章节来看。另外，那些日本韩国人写的《图解XXX》感觉都不喜欢。2. 算法的书够薄，数据结构与算法分析的点基本都涵盖了，而且喜欢它的示例代码是Java写的，新出了第3版。可与上一本对比着读，厚一些，也多些图，但知识点没上面的全，也是Java的。PS： 、，都是专栏文章，讲得并不系统，可以当兴趣读物来看。数学系偏爱无比枯燥很多公式的， 计算机系喜欢这本实用主义的。3. 架构设计的书也是教科书，最难得的是，这本老书在十年后的去年升级了第二版，所以感觉鲜活了好多，也许是最鲜活的一本架构书。由于人类与生俱来的惰性，计算机原本科学的、精准的设计方式，有了敏捷的借口之后就很难再维持了。本书就是在这种背景下，提出由风险来决定设计的度。除了开始的风险驱动部分，其余部分就是规规矩矩标标准准的架构师教科书。广告词是 “地球上有这么一个团队，将运维推向极限高度”，稍嫌标题党，很多值得翻的东西。关于高可靠性的软件，学校里不会教，出来社会却要面对的那部分，英文的原标题更清晰。淘宝出品，大型互联网站的科普入门书。同是入门级读物，如果还有个高可用50条原则，那就齐了。那么多微服务的书，还是这本比较不像赚快钱的。前几年参加各种技术会议，CAP，最终一致性，RWN，向量时钟，Paxos，一致性哈希，Gossip什么的能灌你一耳朵。而现在，你只要在家安安静静的看书就够了。不过这个领域发展太快，又一年过去了，期望它可以持续出新版。PS： 关于设计模式，我以前曾经有过很多很多本，GOF23啦，企业应用架构模式啦，EIP啦， POSA 5卷本啦，反模式啦，JavaEE/SOA/Restful的模式啦。但现在觉得对新人来说，一本Java写的，知道什么叫设计模式就够了。作者维护着 。不过中文书名叫“必读”有点过。4. Java语言的书Java并发经典，人手一本不用多说了。国人新作，流畅易读，内容也比上面一本来得新。Java8的新特性讲得最全最仔细的。理解虚拟机并不是那么难，Java程序员来说，很多知识其实是必须的。另外还有几本类似主题的书，忽然一下子都出来了。比起多年前那部调优圣经，讲得更加深入，也更加贴近现在的JDK。可以从里面挑些知识点来，做Java调优的面试题。不同于那些动辄BDD的高深书籍，专注于如何写“好”的，可维护的单元测试，拿来给团队看，能省很多口水。PS：外界一致推崇，但有点太过誉了。另外有点旧了，而且作者思路随意，译者语言晦涩，新程序员还是建议同时再看两卷。6. 程序员的自我修养PS. 最近没买什么新书，随便说点旧书:，Pragmatic Programmer-注重实效的程序员开山之作，翻译的马达维文笔也和熊节一样好。和 ，英文名是很相近的《Clean Code》和 《Clean Coder》，应该接替成为必看的系列，因为后者太厚了，而且也有不少过时的东西，要自己去过滤。很厚，但最有价值就是前面几章的洗脑篇，具体实作不如薄薄的。关于敏捷的书，最开始的那本就很好，再随便找本Scrum的流程看看就够了，也不错。，经常在组织里推行新技术的同学可以看下，七种怀疑论者模式，脑海中一幅幅熟悉的面孔。PS. 温伯格的书网上很推崇，《成为技术领导者》之类的，但我觉得年代太远，读起来其实没多大意思，一两个鸡汤观点还要自己从书里慢慢淘，有那功夫不如看点别的。","state":"published","sourceUrl":"","pageCommentsCount":0,"canComment":false,"snapshotUrl":"","slug":,"publishedTime":"T21:44:33+08:00","url":"/p/","title":"我的Java后端书架","summary":"作者：calvin本书架主要针对Java后端开发与架构。更新记录：4.0版把第五部份－具体技术的书整块拿掉了。《TCP/IP详解 卷1:协议》出到了第二版，增加《SRE：Google运维解密》，《Java8 实战》。更偏爱那些能用简短流畅的话，把少壮不努力的程序员所…","reviewingCommentsCount":0,"meta":{"previous":null,"next":null},"commentPermission":"anyone","commentsCount":0,"likesCount":0}},"annotationDetail":null,"commentsCount":18,"likesCount":96,"FULLINFO":true}},"User":{"amin706":{"isFollowed":false,"name":"Larry","headline":"
奇点日报创始人，追求产品交互和设计的产品经理一枚
高逼格程序员技术分享平台 → \n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光
邮箱 → ","avatarUrl":"/v2-a5db75ec863beb_s.jpg","isFollowing":false,"type":"people","slug":"amin706","bio":"有情怀→渴望做出一款颠覆性App的代码工作者","hash":"fd983d762fb8","uid":528000,"isOrg":false,"description":"
奇点日报创始人，追求产品交互和设计的产品经理一枚
高逼格程序员技术分享平台 → \n『心动屋』→ 发现令您心动的好物\n『壹日程』→ 专注任务管理和待办计划提醒
\n『拾光记』→ 拾起你走过的时光
邮箱 → ","profileUrl":"/people/amin706","avatar":{"id":"v2-a5db75ec863beb","template":"/{id}_{size}.jpg"},"isOrgWhiteList":false,"badge":{"identity":null,"bestAnswerer":null}}},"Comment":{},"favlists":{}},"me":{},"global":{},"columns":{"lishichao":{"following":false,"canManage":false,"href":"/api/columns/lishichao","name":"互联网笔记","creator":{"slug":"amin706"},"url":"/lishichao","slug":"lishichao","avatar":{"id":"v2-05a3efacf81bef39a0f44","template":"/{id}_{size}.jpg"}}},"columnPosts":{},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldAddVideo":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false},"sys":{}}