具有特色 一个好的RESTfulAPI (具有特色一个字怎么说)
本文目录导航：
一个好的RESTfulAPI，具有特色
一个好的RESTfulAPI，应该具有以下特色：
这个API应该是对阅读器友好的，能够很好地融入Web，而不是与Web貌合神离。
1.阅读器是最经常出现和最通用的REST客户端。
好的RESTfulAPI应该能够经常使用阅读器HTML实现一切的测试（不须要经常使用编程言语）。
这样的API还可以很繁难地经常使用各种智能化的Web性能测试、性能测试工具来做测试。
Web前端运行（基于阅读器的RIA运行、移动App等等）也可以很繁难地将多个RESTfulAPI的性能组合起来，建造Mashup类的运行。
这个API中所蕴含的资源和关于资源的操作，应该是直观和容易了解的，并且合乎HTTP协定的要求。
REST开发又被称作“面向资源的开发”，这说明关于资源的形象，是设计RESTfulAPI的外围内容。
RESTfulAPI建模的环节与面向对象建模相似，是以名词为外围的。
这些名词就是资源，任何可命名的形象概念都可以定义为一个资源。
而HTTP协定并不是一种传输协定，它实践提供了一个操作资源的一致接口。
关于资源的任何操作，都应该映射到HTTP的几个有限的方法（罕用的有GET/POST/PUT/DELETE四个方法，还有不罕用的PATCH/HEAD/OPTIONS方法）下面。
所以RESTfulAPI建模的环节，可以看作是具有一致接口解放的面向对象建模环节。
依照HTTP协定的规则，GET方法是安保且幂等的，POST方法是既不安保也不幂等的（可以用来作为一切写操作的通配方法），PUT、DELETE方法都是不安保但幂等的。
将对资源的操作正当映射到这四个方法下面，既不适度经常使用某个方法（例如适度经常使用GET方法或POST方法），也不参与过多的操作以致于HTTP的四个方法不够用。
2.假设发现资源上的操作过多，以致于HTTP的方法不够用，应该思考设计出更多的资源。
设计出更多资源（以及相应的URI）关于RESTfulAPI来说并没有什么坏处。
这个API应该是松耦合的。
RESTfulAPI的设计包括了三个墨守成规、由低到高的档次：资源形象、一致接口、超文本驱动。
正是这三个档次确保了RESTfulAPI的松耦合性。
3.当设计面向互联网的API时，松耦合变成了一种“必定有”的强需求。
紧耦合的API十分软弱，一旦发布进来，主机端和客户端都不可继续退化。
尤其是主机端，发布进来的接口基本不敢改，改了之后，简直一切客户端运行立刻不可反常上班。
REST这种架构格调就是紧耦合API的解毒剂，这个话题可以谈的很深，这里就不倒退了。
感兴味的读者可以参考《REST实战》。
这个API中所经常使用的表述格局应该是经常出现的通用格局
在RESTfulAPI中，关于资源的操作，是经过在主机端-客户端之间传递资源的表述来直接实现的。
资源的表述可以有很多种格局，并且在照应和恳求中的资源表述格局也会有所不同。
GET/POST照应中的资源表述格局，经常出现的有HTML、XML、JSON；POST/PUT恳求中的资源表述格局，经常出现的有规范的HTML表单参数、XML、JSON。
4.这些经常出现表述格局，处置起来十分容易，有少量的框架和库提供支持。
所以除非有很正当的要求，理论不须要经常使用自定义的私有格局。
经常使用HTTP照应形态代码来表白各种出错状况
HTTP照应形态代码，是HTTP协定这个一致接口中用来表白出错状况的规范机制。
照应形态代码分红两局部：statuscode和reasonphase。
两局部都是可定制的，也可以经常使用规范的statuscode，只定制reasonphase。
5.假设一个所谓的“RESTfulAPI”关于任何恳求都前往200OK照应，在照应的信息体中前往出错状况信息，这种做法显然不合乎“确保操作语义的可见性”这个REST架构格调的基本要求。
这个API应该关于HTTP缓存是友好的
6.充沛应用好HTTP缓存是RESTfulAPI可伸缩性的基本。
HTTP协定是一个分层的架构，从两端的useragent到originserver之间，可以拔出很多两边组件。
而在整个HTTP通讯链条的很多位置，都可以设置缓存。
HTTP协定内建有很好的缓存机制，可以分红过时模型和验证模型两套缓存机制。
假设API设计者齐全没有思考过如何应用HTTP缓存，那么这个API的可伸缩性会有很多疑问。
RESTfulAPI系列之requests的照应
在深化讨论Python的requests模块的经常使用时，咱们首先关注的是如何处置RESTful API或HTTP接口的照应。
当调用这些API或接口后，主机理论会前往一个HTTP照应，其中蕴含了多种类型的信息，如文本、JSON、XML等。
requests模块能够智能解码这些文本类照应，使得开发者能够直接访问并应用这些数据。
提取照应的文本内容时，咱们理论关注的是照应的文本局部。
例如，在恳求GitHub期间线后，前往的HTTP照应蕴含了文本信息，可以经过照应答象的text属性失掉。
requests模块会基于HTTP头部推测照应的编码，当访问文本内容时，会经常使用推测的编码。
为了确保正确读取文本，开发者可以审核并修正照应的编码。
假设须要经常使用自定义编码，可以应用codecs模块注册编码称号，并将该称号作为的值，以便requests模块正确处置编码。
在某些状况下，API或者前往二进制内容，如图片或文件。
此时，开发者可以经过照应答象的content属性访问二进制数据。
关于二进制照应内容，requests模块还提供了繁难的下载性能，如保留图片或其余文件。
关于API前往的JSON数据，requests模块内置了JSON解码器，简化了JSON数据的处置环节。
经常使用()方法可以将JSON字符串转换为Python对象，如字典或列表。
若JSON解码失败，会抛出意外。
此外，审核恳求形态更介绍经常使用_for_status()或检查_code能否合乎预期，以确保恳求成功。
在特定状况下，开发者或者须要失掉主机的原始套接字照应，这时可以经常使用照应答象的raw属性。
但是，理论倡导经常使用_content方法，以更高效的模式处置少量数据流，特意是视频流或大附件时，这种方法可以灵敏调整分块大小以顺应不同需求。
总结而言，经过经常使用requests模块，开发者能够灵敏、高效地处置RESTful API和HTTP接口的照应，无论是文本、JSON、XML还是二进制内容。
经过把握这些技术，开发者可以更好地利用API提供的数据，启动数据剖析、处置和集成，从而提高开发效率和运行品质。
接口调用失败怎样处置？
处置接口调用失败的方法重要包括：审核接口地址和参数、检查接口文档、审核网络衔接、参与失误处置和重试机制，以及咨询接口提供者失掉支持。
接口调用失败在软件开发中是一个经常出现疑问，或者由多种要素造成。
首先，开发者应审核调用的接口地址能否正确，以及传递给接口的参数能否满足要求。
例如，在调用RESTful API时，须要确保URL门路和HTTP方法（GET、POST等）正确无误，同时传递给API的数据格局（如JSON）也要合乎接口规范。
其次，查阅接口文档是处置接口调用失败的关键步骤。
文档理论会提供接口的经常使用方法、参数说明、前往值示例以及失误代码等信息。
经过细心阅读文档，开发者可以了解接口的预期行为，从而对如实践调用状况找出或者的疑问所在。
此外，网络衔接疑问也或者造成接口调用失败。
开发者应审核自己的网络环境能否稳固，以及能否有访问接口主机的权限。
例如，某些接口或者只准许特定的IP地址或域名访问，这时就须要性能相应的网络访问规则。
为了提高系统的强健性，开发者还应在代码中参与失误处置和重试机制。
当接口调用失败时，程序应能够捕捉意外并给出友好的失误信息，同时依据须要启动重试。
例如，可以设置一个最大重试次数，在每次失败后期待一段期间再次尝试调用接口。
最后，假设以上方法都不能处置疑问，开发者可以咨询接口提供者失掉支持。
在咨询提供者时，应具体形容遇到的疑问、提供调用接口的日志信息，并尽或者提供复现疑问的步骤，以便提供者能够更快地定位并处置疑问。
phper