我试图了解基于REST的API究竟是什么。据我所知,它只是在API中编写函数的惯例?所有功能应该是GET / POST / DELETE / PUT形式?因此,例如REST API中的函数可以是
public string getLastName(User x)
{
return x.lastName;
}
我对JSON / XML如何在这方面发挥作用感到困惑?
答案 0 :(得分:3)
它不仅仅是一个惯例。 REST API背后的概念是您使用HTTP谓词访问它,并且已映射这些谓词的函数以执行所描述的操作。
例如:
GET 会将数据返回给来电者/发件人
删除将删除记录
它更进一步,但其中很多都是基于依赖HTTP来提供一致性。例如,在RESTful服务中,您可以使用Accept
HTTP标头分别通过提供application/json
或application/xml
值来请求JSON响应或XML响应。这只是一个简单的例子,由实施者决定他们的API如何工作,但它强调了利用HTTP的重要性。
为什么选择JSON / XML?
同样,使用JSON和XML是因为它们是通过Web表示和传输数据的普遍和标准方式。 JSON(JavaScript Object Notation)在进行数据传输时非常常见(特别是在GET请求上),因为大多数请求来自JavaScript,并且JS可以轻松地与JSON交互,而无需在处理XML时进行所需的解析。另一方面,XML提供了自己的好处,例如使用模式和命名空间的能力。您可能已经意识到每个的好处/缺点,但这是一个单独的讨论。重点是JSON / XML是在REST API中传递数据的主要方式,因为它们都是Web的事实标准。
有很多好的资源可以获得更多信息,这篇MSDN文章可能会有所帮助:http://msdn.microsoft.com/en-us/library/dd203052.aspx
答案 1 :(得分:2)
围绕REST存在很多困惑和误解。不幸的是,找到与REST意味着完全相反的应用程序并将自己称为RESTful而不是真正的REST应用程序更为常见。
据我所知,这只是在API中编写函数的惯例吗?
不,REST不仅仅是在API中编写函数的约定,也不像其他答案那样与SOAP或HTTP直接相关。 REST是一种软件架构风格,受到为Web本身做出的成功设计决策的启发。换句话说,REST API应该像网站一样工作。
当您进入网站时,您会访问一个主页,了解网站的内容,HTML文档将包含指向您所需资源的超链接。唯一的带外信息是资源本身的媒体类型,而不是如何找到它们。例如,当您输入StackOverflow时,您知道哪些问题和答案是什么,并且您寻找指向它们的链接。您的浏览器如何呈现这些链接,您如何选择它们并遵循它们与其他网站(如电子邮件或新闻网站)不同。它与众不同的是您所追求的资源的媒体类型。
REST API应该如何工作。除了详细说明资源的用途外,客户不应该依赖任何带外信息。他们应该连接到一个主页,返回他们应该遵循的链接以做他们需要的任何事情。如果API没有这样做,那么它不是REST。周期。
我喜欢称那些API" street-REST",因为人们经常通过复制他们在其他API中看到的东西来实现它们,这些API也称为REST,以及其他人谈论REST。
所有功能应该是GET / POST / DELETE / PUT形式?
这是一个常见的混乱,你会看到很多,包括将其与CRUD操作混淆的人,或者REST不允许任何其他动词等等。'公牛。
REST独立于任何特定协议,因此说函数应遵循HTTP方法是没有意义的。 REST将您的应用程序限制在一个统一的界面中,这意味着无论您应该使用哪种协议,都必须尽可能地遵守标准化行为。如果您通过HTTP实现REST应用程序,这意味着您的API必须坚持使用HTTP方法进行客户端 - 服务器交互,这意味着您不能像使用HTTP的某些应用程序那样发明其他HTTP方法。如果您更改了通信协议,客户需要在输入API之前知道该信息,以及更多的带外信息。
如何在代码上实现此功能与REST无关。 REST不是一种发展模式或哲学,而是一种建筑风格。
我对JSON / XML如何在这方面发挥作用感到困惑?
对此也存在很多困惑。在REST应用程序中,您应该定义具有状态的抽象实体,描述您需要的所有行为。 API将作为客户端和服务器之间传输媒体类型表示的渠道。 REST意味着代表性国家转移。客户端请求的URI是该资源的标识符,该请求的元数据将告诉服务器客户端准备接受哪些媒体类型。 JSON / XML根本不会在REST中发挥任何直接作用。它们只是一种表示媒体类型,计算机更容易解析和获取信息,与text / html等格式形成鲜明对比,后者旨在通过浏览器进行人工可视化。
例如,请使用StackOverflow本身。抽象意义上的问题是什么?这是一个信息请求。如何正式定义抽象资源?有作者,有问题的实际文本,还有赞成票和评价,评论和可能的答案等等,所有这些都是自己的抽象资源定义。实际数据存储在某个地方的数据库中,当您请求主页时,它会返回带有标识这些问题的URI的链接。以此问题为例,它具有URI http://stackoverflow.com/questions/24092517
。当我想在浏览器上呈现的漂亮文档中读取该问题时,我将请求该URI,但是通过Accept
标题告诉服务器我想要text/html
表示,并且我的浏览器知道如何将HTML呈现为漂亮的页面。另一方面,当我想要将该问题存储回数据库时,我不需要渲染一个漂亮的文档页面所需的所有可爱的东西,所以我问一个格式&#39 ;更容易解析,并且不包含大量不必要的信息,如JSON或XML。
构建街道REST API的大多数人都明白这一点,但他们错过了最有趣的部分,即您不仅限于已经存在的媒体类型。您可以创建仅存在于API中的私有媒体类型,或您公司的应用程序生态系统。因此,例如,不管调用所有JSON文档的媒体类型application/json
,而不是它们的内容,我们都可以使用自定义媒体类型来更准确地反映特定类型的资源。因此,对于以JSON格式表示的StackOverflow问题,我们可以有一个application/vnd.stackoverflow.question.v1+json
。一旦这样做,而不是浪费时间记录已经通过通信协议标准化的操作,您应该专注于记录该自定义媒体类型以及如何与其进行交互,而与通信协议无关。一旦明确了,客户就可以使用任何可用的协议与您的服务进行交互。
如果您了解这三个要点,就可以了解REST的用途。通过使用超链接作为应用程序状态的引擎,您不会与实施的任何特定时间点相关联。您的服务器可以随意发展,您可以根据需要更改URI,并且客户不会中断。通过坚持使用标准化协议,通用客户可以更轻松地使用您的API,更不用说如果开发人员已经知道您已经知道如何进行整合,那么它就更容易理解。打破协议。通过将您的设计和文档工作集中在您的媒体类型而不是协议详细信息和URI语义上,您可以避免引入驱动API所需的更多带外信息,并且您的客户也更容易适应变化
答案 2 :(得分:0)
REST API 充当中间人,在 Web 服务和想要使用 Web 服务的某些资源进行操作的应用程序之间传递数据包,为此,Json 发挥了作用,这有助于通过网络进行数据传输/通信。渠道。当一个应用程序想要获取资源列表时,它实际上是从数据库中获取复杂的数据或查询集,这些数据或查询集经过序列化后变成简单数据类型,然后变成json遍历通道。
答案 3 :(得分:-1)
我对JSON / XML如何在这方面发挥作用感到困惑?
JSON/XML
称为流数据格式。还有其他一些,但多年来这两个因为它们提供的低延迟而变得如此受欢迎。 XML可能仍然比JSON更受欢迎,但JSON更紧凑。
使用它们的另一个主要原因是它们几乎受到所有语言及其框架的支持。