Exposing Apex as SOAP and REST Web Services

同学们，今天我们来聊一个特别实用的主题——怎么把你的Apex代码变成对外的Web服务，让外部的应用程序也能调用你Salesforce里的逻辑和数据。 想象一下，你的Salesforce里有一个很强大的业务功能，比如计算折扣、查询库存，或者处理订单。现在，公司另一个系统，比如一个电商网站或者手机App，也想用这个功能。怎么办呢？我们就可以把Apex方法包装成Web服务，让外部系统通过标准的网络调用来访问。 这里有两种主流的方式：SOAP Web服务和REST Web服务。听起来有点专业，但其实很好理解。我们先说SOAP方式。 SOAP，你可以把它想象成一种非常正式的、带信封的邮寄方式。你要发一封信，必须有固定的格式：信封上要写清楚寄件人、收件人，信纸里的内容也要按照规定的XML结构来写。在Salesforce里，你只需要在一个Apex方法前面加上一个特殊的注解，就像贴了一张“SOAP服务”标签。这样，Salesforce就会自动帮你生成一个WSDL文件——这相当于服务的说明书，告诉外部系统怎么调用，需要传什么参数，返回什么结构。外部系统拿着这个说明书，就可以用SOAP协议来调用了。优点是结构严谨，支持强类型，适合企业级系统的对接。 再来看REST方式。REST更像是一种随性的明信片。不需要复杂的信封，你可以用简单的HTTP请求，比如GET、POST这些我们平时上网就在用的方法，再加上一个URL，就能访问服务。在Apex里，我们用Apex REST注解，把一个类标记为REST资源，然后里面的方法对应不同的HTTP动作，比如@HttpGet表示获取数据，@HttpPost表示创建数据。这种方式更轻量，适合移动端、网页前端这些场景，数据格式通常用JSON，更容易阅读和处理。 这两者都是我们Salesforce平台开放出去的能力。所以当有人问：“我的外部系统能不能用你Salesforce里的逻辑？”你就可以自信地回答：当然可以，我们有APEX Web服务，SOAP和REST随你选。 简单总结一下：SOAP像正式公文，严谨但笨重；REST像聊天消息，灵活又轻便。具体用哪个，看对方系统的习惯和你的场景需求。下一节课我们会深入每个方式的代码写法，现在你只需要记住这张Slide的核心思想：Apex代码可以通过两种方式暴露成Web服务，让你的Salesforce能力走出平台，连接万物。 好了，这就是今天的内容，我们下次见。