- \n
- In the same way that you can write an Apex method and expose it via a SOAP interface, you can now have an Apex method exposed via REST. That\u2019s really useful because one of the properties of the REST API is that you can do updates, but they’re on individual records. For example, let\u2019s say you want to do an atomic update where you want to update an account and a contact and you want them to both succeed or both fail. It\u2019s not possible to do that with the REST API. You would need to do a PATCH on the account and a PATCH on the contact.<\/li>\n<\/ul>\nApex Soap<\/b><\/div>\n
- \n
- Strictly speaking it\u2019s not an an API, that enables you to expose Apex methods via SOAP. You might write your own Apex method that takes parameters of a person name, company name and phone number and then creates an account and a contact in one operation as far as the client is concerned. You can then expose that method as a service operation by using the @WebService annotation on the method. So you can expose it via SOAP and download the WSDL and that all works very well and people have been using it for a long time.<\/li>\n<\/ul>\nBULK API<\/b><\/div>\n
- \n
- Bulk API which has been around longer than the REST API. It\u2019s an asynchronous API, and it has the ability to work with large data sets like 500,000 records. But you wouldn’t want to use this API if you just need a handful of records and you want to create a dynamic UI that\u2019s easy to program. It\u2019s more of a special purpose API for loading lots of data.<\/li>\n<\/ul>\nMetadata API<\/b><\/div>\n
- \n
- The Metadata API\u2019s focus \u2013 as its name implies \u2013 is metadata. So it gives you an API to manipulate layouts, Visualforce pages, Apex triggers and classes \u2013 pretty much everything you can do to your org from the browser interface you can also do from the Metadata API. Not just retrieving them either \u2013 tools such as the Force.com IDE use the Metadata API to make changes in your org.<\/li>\n<\/ul>\nSOAP API<\/b><\/div>\n
- \n
- Probably the most well-known API is the SOAP API. As its name implies, it uses SOAP as a wrapper for API operations. Probably the bulk of our API traffic is from the SOAP API because it\u2019s been there a long time.<\/li>\n<\/ul>\nApex API<\/b><\/div>\n
- \n
- The Metadata API allows you to upload Apex classes, but tools such as the Force.com IDE need a bit more functionality. The Apex API exposes API objects and calls that allow you to execute an anonymous block of code, compile classes, and run tests. Most developers won’t ever need to use the Apex API directly, but many benefit from its use in the IDE.<\/li>\n<\/ul>\nREST<\/b><\/div>\n
- \n
- If you just need to make a point-to-point call, in some ways SOAP can be overkill. You need an envelope and headers and a whole spec that explains how to process these messages. But if you’re just sending a message from a client to a server and sending back a response, you can use something much simpler which is REST.<\/li>\n<\/ul>\nREST API<\/b><\/div>\n
- \n
- The REST API went into early access about a year ago, and has been generally available (GA) since Spring \u201911, and it does encompass some metadata operations. But in the REST API the metadata is read only. So a developer can perform a similar operation from REST, for example, you could retrieve a list of all the objects that are available in the system. Then for a given object, you could retrieve the list of its fields. So you can actually build dynamic interfaces with the REST API.<\/li>\n<\/ul>\nStreaming API<\/b><\/div>\n
- \n
- Where the rest of the APIs give you the ability to make a call and you get back data or you update data, the Streaming API allows you to create a pushtopic based on a query and get updates on an ongoing basis when the results of that query change. So you can say \u2018select name from some object\u2019 and then subscribe to the topic channel.<\/li>\n
- In the absence of any changes, you get nothing \u2013 your app sits there and patiently waits. But as soon as someone creates or updates a record that matches your pushtopic query, you’ll get a notification that contains the fields that are in the SELECT statement of the topic query.<\/li>\n<\/ul>\nChatter API<\/b><\/div>\n
- \n
- Chatter API presents a higher-level abstraction of that data. Instead of dealing with the underlying objects, you’re dealing with a slightly abstract representation of a user\u2019s Chatter feed and the entries in it. It\u2019s designed so that you can do one call and get pretty much everything you need in the 80\/20 case. You might need to drill down a little bit, but certainly most applications that are manipulating Chatter are making pretty standard requests. Like the Chatter desktop, for example. Your application might be showing all the posts on a user\u2019s Chatter feed and with the Chatter API, you can get that all in one request.<\/li>\n<\/ul>\nTooling API [Latest]<\/b><\/div>\n
- \n
- Tooling API provides SOAP and REST interfaces that allow you to build custom development tools for Force.com applications. While other Salesforce APIs can handle deployment, Tooling API was designed from the ground up to support the entire development lifecycle, including design, implementation, deployment, and maintenance.<\/li>\n<\/ul>\n
<\/p>\n
Which API should I use & when <\/a><\/p>\n
Salesforce APIs- What They Are & When to Use Them<\/a><\/p>\n
- Tooling API provides SOAP and REST interfaces that allow you to build custom development tools for Force.com applications. While other Salesforce APIs can handle deployment, Tooling API was designed from the ground up to support the entire development lifecycle, including design, implementation, deployment, and maintenance.<\/li>\n<\/ul>\n
- Chatter API presents a higher-level abstraction of that data. Instead of dealing with the underlying objects, you’re dealing with a slightly abstract representation of a user\u2019s Chatter feed and the entries in it. It\u2019s designed so that you can do one call and get pretty much everything you need in the 80\/20 case. You might need to drill down a little bit, but certainly most applications that are manipulating Chatter are making pretty standard requests. Like the Chatter desktop, for example. Your application might be showing all the posts on a user\u2019s Chatter feed and with the Chatter API, you can get that all in one request.<\/li>\n<\/ul>\n
- The REST API went into early access about a year ago, and has been generally available (GA) since Spring \u201911, and it does encompass some metadata operations. But in the REST API the metadata is read only. So a developer can perform a similar operation from REST, for example, you could retrieve a list of all the objects that are available in the system. Then for a given object, you could retrieve the list of its fields. So you can actually build dynamic interfaces with the REST API.<\/li>\n<\/ul>\n
- If you just need to make a point-to-point call, in some ways SOAP can be overkill. You need an envelope and headers and a whole spec that explains how to process these messages. But if you’re just sending a message from a client to a server and sending back a response, you can use something much simpler which is REST.<\/li>\n<\/ul>\n
- The Metadata API allows you to upload Apex classes, but tools such as the Force.com IDE need a bit more functionality. The Apex API exposes API objects and calls that allow you to execute an anonymous block of code, compile classes, and run tests. Most developers won’t ever need to use the Apex API directly, but many benefit from its use in the IDE.<\/li>\n<\/ul>\n
- Probably the most well-known API is the SOAP API. As its name implies, it uses SOAP as a wrapper for API operations. Probably the bulk of our API traffic is from the SOAP API because it\u2019s been there a long time.<\/li>\n<\/ul>\n
- The Metadata API\u2019s focus \u2013 as its name implies \u2013 is metadata. So it gives you an API to manipulate layouts, Visualforce pages, Apex triggers and classes \u2013 pretty much everything you can do to your org from the browser interface you can also do from the Metadata API. Not just retrieving them either \u2013 tools such as the Force.com IDE use the Metadata API to make changes in your org.<\/li>\n<\/ul>\n
- Bulk API which has been around longer than the REST API. It\u2019s an asynchronous API, and it has the ability to work with large data sets like 500,000 records. But you wouldn’t want to use this API if you just need a handful of records and you want to create a dynamic UI that\u2019s easy to program. It\u2019s more of a special purpose API for loading lots of data.<\/li>\n<\/ul>\n
- Strictly speaking it\u2019s not an an API, that enables you to expose Apex methods via SOAP. You might write your own Apex method that takes parameters of a person name, company name and phone number and then creates an account and a contact in one operation as far as the client is concerned. You can then expose that method as a service operation by using the @WebService annotation on the method. So you can expose it via SOAP and download the WSDL and that all works very well and people have been using it for a long time.<\/li>\n<\/ul>\n
![\"](\"http:\/\/cdnblog.webkul.com\/blog\/wp-content\/uploads\/2015\/10\/SF1-e1442400479311.jpg\")
<\/a><\/div>\n