HTTP 定义了一组请求方法, 以表明要对给定资源执行的操作。指示针对给定资源要执行的期望动作. 虽然他们也可以是名词, 但这些请求方法有时被称为HTTP动词。
本系列主要翻译自《ASP.NET MVC Interview Questions and Answers 》- By Shailendra Chauhan,想看英文原版的可访问http://www.dotnettricks.com/free-ebooks自行下载。该书主要分为两部分,ASP.NET MVC 5、ASP.NET WEB API2。本书最大的特点是以面试问答的形式进行展开。通读此书,会帮助你对ASP.NET MVC有更深层次的理解。 由于个人技术水平和英文水平也是有限的,因此错误在所难免,希
请求报文以 HTTP 方法开头,随后是路径和要使用的HTTP 协议版本,这三部分称为请求行。
The Representational State Transfer (REST)架构风格不是可以购买的技术,也不是可以添加到软件开发项目中的库。REST是一种世界观,将信息提升为我们构建的体系结构的第一流元素。
做出一个好的API设计很难。API表达的是你的数据和你的数据使用者之间的契约。打破这个契约将会招致很多愤怒的邮件,和一大堆伤心的用户-因为他们手机上的App不工作了。而文档化只能达到一半的效果,并且也很难找到一个愿意写文档的程序员。
参考官方文档:https://tools.ietf.org/html/rfc2616
经过3个月的碎片时间的翻译和校验,由长沙.NET技术社区翻译的英文原文文档《Microsoft REST API指南 》已经翻译完成,现刊载前十一章如下,欢迎大家点击“查看原文”按钮,查看指南的完整内容。
WEB API的应用场景非常丰富,例如:将已有系统的功能或数据开放给合作伙伴或生态圈;对外发布可嵌入到其他网页的微件;构建前后端分离的WEB应用;开发跨不同终端的移动应用;集成公司内部不同系统等等。在上述场景里,你可能是WEB API的使用者,也可能是设计者,但你知道如何评判WEB API的优劣吗?
前面我们说了,如果API的设计更规范更合理,在很大程度上能够提高联调的效率,降低沟通成本。那么什么是好的API设计?这里我们不得不提到REST API。
客户端(前端)和服务器(后端)之间的通信通常不是超级直接的。因此,我们使用一个叫作“应用编程接口”(或 API)的接口,作为客户端和服务器之间的中介。
请求--响应类的API的典型做法是,通过基于HTTP的Web服务器暴露一个/套接口。API定义一些端点,客户端发送数据的请求到这些端点,Web服务器处理这些请求,然后返回响应。响应的格式通常是JSON或XML。
什么是RESTful 一种软件架构风格、设计风格,而不是标准,只是提供了一组设计原则和约束条件。它主要用于客户端和服务器交互类的软件。基于这个风格设计的软件可以更简洁,更有层次,更易于实现缓存等机制。 一、URI规范 1.不用大写; 2.用中杠 - 不用下杠 _ ; 3.参数列表要encode; 4.URI中的名词表示资源集合,使用复数形式。 5.在RESTful架构中,每个网址代表一种资源(resource),所以网址中不能有动词,只能有名词(特殊情况可以使用动词),而且所用的名词往往与数据库的表格名对应
RESTful API 全称 REpresentational State Transfer (表现层状态转化) 服务器上的文本,图片,网页,视频等都是资源(Resources), 通常使用一个唯一的URI(统一资源定位符)来表示. “资源”具体呈现出来的形式,叫做它的”表现层”(Representation)
原文出处:RESTful API Design. Best Practices in a Nutshell. 原文:RESTful API Design. Best Practices in a Nutshell. 作者:Philipp Hauer 项目资源的URL应该如何设计?用名词复数还是用名词单数?一个资源需要多少个URL?用哪种HTTP方法来创建一个新的资源?可选参数应该放在哪里?哪些不涉及资源操作的URL呢?实现分页和版本控制的最好方法是什么?因为有太多的疑问,设计RES
项目资源的URL应该如何设计?用名词复数还是用名词单数?一个资源需要多少个URL?用哪种HTTP方法来创建一个新的资源?可选参数应该放在哪里?那些不涉及资源操作的URL呢?实现分页和版本控制的最好方法是什么?因为有太多的疑问,设计RESTful API变得很棘手。在这篇文章中,我们来看一下RESTful API设计,并给出一个最佳实践方案。
什么是API规范 API 是模块或者子系统之间交互的接口定义。好的系统架构离不开好的 API 设计,而一个设计不够完善的 API 则注定会导致系统的后续发展和维护非常困难。在关键环节制定明确的API规范有助于 Service 对内提高产品间互通的效率,对外提供一致的使用体验,也有助于更好地被集成。 对于API规范,比较知名的是 OpenAPI Specfication[1] 和 Google API Design Guide[2]。前者针对 RESTful API 设计在细节层面给出了非常具体的规定,已经成
在资源中中一切都被认为是资源,每个资源有对应的Url标识。处理资源使用Get,Post,Put,Delete等http方法操作实现创建,读取,修改,删除等操作。客户端通过四个Http动词,对服务器端资源进行操作,实现“表现层状态转换”表现是指资源的表现。客户端和服务器之间,传递这种资源的某种表现层;无状态,每个请求是独立的,,从客户端的每个请求都必须包含所有的必须信息
OData用于定义构建和使用RESTful API所需的最佳实践。它可以帮助您找到更改,定义可重用过程的函数和发送批量请求等。
RESTful 是一种软件架构风格,其面向资源。基于 HTTP 协议实现。 设计概念和准则 所有事物都可以被抽象为资源。 每一个资源都有唯一的资源标识,对资源的操作不会改变这些标识。 所有操作都是无状态的。 请求方法 get 获取 post 附加新的资源 (新建) head 请求获取由 REQUEST-URI 所标识的资源的响应信息报头 put 请求服务器存储一个资源,并用 REQUEST-URI 作为其标识(更新) delete 请求服务器删除 REQUEST-URI 所标识的
进入正文之前,先带着小伙伴们了解几个名词,源自百度百科。 标题中涉及的核心名词API,restful
本文讨论的内容主要是请求风格,所以本文中所说RPC侧重于HTTP请求风格,而非java中的RPC设计模式。 有关REST和RPC的讨论或争论一直活跃在各个技术角落,最近也关注了不少,看了很多人的看法之后,我意识到这个问题可以帮助我照亮自己的知识死角:为什么我喜欢REST的请求风格(资源导向)比RPC(操作导向)多一点呢? 是因为RPC的请求风格天生邪恶吗? 还是REST就是灵丹妙药? 两种请求风格长分别长什么样子 在比较这两种请求风格之前,让我们看看他们究竟长什么样子。 HTTP 请求 RP
接着上次从SAP API Hub上参考创建的OData 服务:OData -SAP OP 中使用SAP API Hub的API
现代网站越来越多的使用前后端分离架构,先用前端 MVC 框架快速堆砌出 SPA,再用 API 获取动态数据也已经成为日常的开发内容;而用来连接前后端的 API,其重要性也自然言而喻。做为一个前端码农,认识后端的 API 设计方式也是很重要的,今天让我们针对 API 设计来一探究竟。
本篇参考:https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf
正如我们在前一篇文章中看到的,浏览器通过HTTP协议与web应用程序交互,这是我们深入研究这个主题的主要原因。如果用户在网站上输入他们的信用卡信息,攻击者就能在数据到达服务器之前拦截数据,我们肯定会有麻烦。
在 HTTP 协议中,CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道(tunnel)。
在我所见过的 RESTful 接口的实现中,以 GitHub 最让人惊叹。我第一次如此强烈得感受到 REST 接口的美妙,完全满足了我所期待的「接口的形式美感」,简直就是对 REST 规范实现的最佳范本。我觉得每一个后端开发者都应该看一看 GitHub 的 REST 接口文档,感受一下循规蹈矩的美妙。
在前后端分离的 Web 应用架构中,前端专注于页面,同时与后端进行数据交互;而后端则专注于提供 API 接口。在这样的结构下,REST 是一个很流行的前后端交互形式的约定。这只是一套约定,并不是某个技术标准,所以在实际的应用中,对器实现程度完全取决于后端开发者;一些号称 RESTful 的接口并没有那么RESTful。
本文最初发表于 Treblle 网站,经原作者 Vedran Cindrić 授权,InfoQ 中文站翻译并分享。
在上节内容中我们介绍了如何利用数据库主键提升访问性能,本节内容我们继续为大家介绍如何在大规模数据量的场景下提升数据访问效率。
当开发REST API时,从一开始就必须注意安全方面。 REST是通过URL路径元素表达系统中特定实体的手段。REST不是一个架构,而是一种在Web上构建服务的架构风格。 REST允许通过简单的URL(而不是复杂的请求主体或POST参数)与基于web的系统交互。 1 - 授权 (1)保护HTTP方法 RESTful API通常使用GET(读),POST(创建),PUT(替换/更新)和DELETE(删除记录)。 对于每个资源并非都要提供所有这些操作。 必须确保传入的HTTP方法对于会话令牌/API密
Sam花了一整天的尝试,仍然没有在Verizon Media漏洞赏金计划中有所收获,于是,他决定先退出做一些其他事情。他上网准备订购星巴克的礼品卡,作为朋友的生日礼物。
在这篇文章中,我们将讨论我们在内部网络渗透测试期间在戴尔OpenManage Server Administrator(OMSA)中发现的一个文件读取漏洞,漏洞编号为CVE-2020-5377,以及一个针对CVE-2021-21514漏洞修复程序的绕过方案。
领取专属 10元无门槛券
手把手带您无忧上云