Accessing HTTP Response Headers

同学们，今天我们来看一个在使用Salesforce做HTTP请求时，经常会遇到的小细节——怎么获取响应头里的信息，以及不同API版本对响应编码的影响。 假设你写了一个Apex类，去调用外部的Web服务，服务返回了一些数据，还在响应头里附带了有用的元数据，比如分页信息、自定义追踪ID等等。你肯定想在代码里把这些头信息读出来，对吧？那就要用到`outputhttpHeaders_x`这个变量。 记住一个关键点：这个`outputhttpHeaders_x`默认是空的，什么也没有。就像你有一个空盘子，必须先把它变成一个真正的盘子，才能往里面装东西。所以，在访问响应头之前，你必须先手动把它初始化成一个新的Map。比如，你可以写`outputhttpHeaders_x = new Map();`，然后再去做HTTP请求。否则，如果你直接尝试读取它的内容，就会遇到空指针异常。这个坑，早年不少开发者都踩过。 好，拿到了响应头，你可能会关心响应体的文字编码问题。比如返回的是中文、日文等多字节字符，编码如果搞错了，就会变成乱码。这里，Salesforce在API版本演进中有过重要变化。 在API 16.0及更早的版本里，Salesforce比较“固执”，它不管服务器在Content-Type头里声明了什么编码，一律按UTF-8来解码响应体。这在当时可能会导致一些兼容性问题。 但从API 17.0开始，Salesforce变聪明了，它会尊重服务器返回的Content-Type头里指定的字符集。比如服务器说“Content-Type: text/html; charset=Shift_JIS”，那Salesforce就会用Shift_JIS来解码，大大减少了乱码的可能。 所以，如果你在维护老代码，看到莫名其妙的乱码，不妨检查一下类或触发器的API版本。如果低于17.0，可以考虑升级一下，让编码处理更符合标准。 今天的要点就两个：一是访问响应头前一定要先给`outputhttpHeaders_x`建好Map；二是知道API版本会影响HTTP响应的解码方式，新版本更灵活。希望这能帮你少踩几个坑。我们下节课再见！