南昌网站建设公司效果,最简单的做网站,唯品会 一家专做特卖的网站,电子商务网站名称和网址微软发布了创建“RESTful” API的指南。Roy Fielding将这些与REST没有多大关系的API称为HTTP API。 许多组织都发布了创建面向Web的HTTP API的建议#xff0c;甚至是白宫都发布了一份标准——“白宫Web API标准”。近日#xff0c;微软公开了他们的“微软REST API指南2.3”甚至是白宫都发布了一份标准——“白宫Web API标准”。近日微软公开了他们的“微软REST API指南2.3”这是一份全面而成熟的规范。该规范被制定出来主要是供Azure团队在构建云服务时使用。 下面总结了微软API指南的一些关键点感兴趣地读者可以阅读完整的规范。 为了便于API的应用URL应该是人类可读和可构造的而不必借助客户端库。应支持以下HTTP谓词GET、PUT、DELETE、POST、HEAD、PATCH、OPTIONS。不是所有的资源都应该支持所有的谓词。GET、PUT、DELETE和HEAD应该是幂等的。自定义头信息不是必须的。客户端应该不需要在URL中传递个人身份信息参数因为它们可能会暴露在日志文件中。参数应该通过头信息传递。数据应该以流行的格式提供。默认数据编码是JSON。“基本型数值必须遵循RFC4627标准序列化成JSON。”使用API的开发人员应该能够使用喜欢的语言和平台。即使是简单的HTTP工具如curl也应该能够访问服务。API应该支持显式版本。服务应该保持稳定如果可能就不要引入破坏性修改但如果必要它们也应该允许这样做通过增加版本号标识出来。版本应该使用一种Major.Minor方案。服务可以通过Web钩子HTTP回调实现推送通知。 该指南提供了一个例子说明了什么样的URL是结构良好的URL: https://api.contoso.com/v1.0/people/jdoecontoso.com/inbox 而另外一个例子说明了什么样的URL是应该避免的 https://api.contoso.com/EWS/OData/Users(jdoemicrosoft.com)/Folders(…[very long identifier]…) Roy Fielding是REST及HTTP/1.1的作者同时也是Apache基金会的联合创始人。在微软发布这份REST API指南之后不久他就表达了对这份规范的不满“即使是我最糟糕的REST描述也比[微软/aip指南]提供的总结或参考要好很多。”InfoQ联系了Fielding更详细地了解他为什么对这份规范不满意。以下是他的完整回复 我认为像微软这样的公司决定将部分内部文档和开发指南发布到公共论坛尤其是像GitHub这样的开源协作空间是很好的。对于公共对话的这种开放性将极大地改善我们这个行业的工作方式。 对于这份指南我不满意的是这份指南明明是总结了如何在微软的生态系统中开发合理的HTTP API但却冠以REST和RESTful API的标签。REST不等于HTTP这是显而易见的粗略地读下任何有关REST的资料就可以知道。这份指南明显不是基于REST的他们甚至没有设法参考我的工作除了已经被RFC7231废除的RFC2616的部分内容。对于以前深入Web Services世界的人们这是一个常见的错误将REST描述成SOAP/RPC接口的某种HTTP版本。 不管那种错误在实际中多么常见它都不能自称是REST。REST架构风格的大部分属性都源于对其所有约束的坚持而不只是那些与过去已失败的工具类似的约束。如果那些想要使用HTTP构建RPC接口的人们将它们的接口称为HTTP API那么我没有任何意见。它们不是REST的。它们不属于Web。那并不是说它们不能被诚实地描述并实现为HTTP服务。要这样理解它们讨论它们的实现指南而又不觉得需要遵从错误的说法这是值得的。 许多Web服务提供商都使用了HTTP API并且运用得非常成功。大部分云计算都是基于这样的API。 原文地址http://www.infoq.com/cn/news/2016/07/microsoft-rest-api .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
