Salesforce API Support

Salesforce has support for many APIs namely:

 

• 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’s 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’s 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’s 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.

• Strictly speaking it’s 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.

• Bulk API which has been around longer than the REST API. It’s 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’s easy to program. It’s more of a special purpose API for loading lots of data.

• The Metadata API’s focus – as its name implies – is metadata. So it gives you an API to manipulate layouts, Visualforce pages, Apex triggers and classes – 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 – tools such as the Force.com IDE use the Metadata API to make changes in your org.

• 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’s been there a long time.

• 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.

• 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.

• The REST API went into early access about a year ago, and has been generally available (GA) since Spring ’11, 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.

• 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 ‘select name from some object’ and then subscribe to the topic channel.
• In the absence of any changes, you get nothing – 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.

• 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’s Chatter feed and the entries in it. It’s 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’s Chatter feed and with the Chatter API, you can get that all in one request.

• 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.

 

Which API should I use & when

Salesforce APIs- What They Are & When to Use Them

May Salesforce Be With You!!