Salesforce provides a number of APIs to access and manipulate records in its own objects that belong to applications such as CRM; these APIs are also extended to support Custom Objects created by admins or provided by packages installed in the subscriber org. Salesforce dedicates a huge amount of its own and community-driven documentation resources you can reference when educating partners and customer developers on the use of these APIs. Thus, it is important that your application works well with these APIs.
Platform APIs are enabled for Enterprise Edition orgs and above, though if you have a need to consume them in Professional or Group Edition orgs, Salesforce can provide a Partner API token (following security review completion) to enable their use; this is unique to your application and so does not provide access for code other than yours.
Typically, unless you are developing an off-platform utility or integration to accompany your application, you may not find your application consuming these APIs at all, though there are some you might want to consider, highlighted in the following bullets. Keep in mind, however, that if you do, in addition to the Partner API token, the subscriber org's daily API limit will also be consumed; hence, ensure that your usage is as network optimal as possible.
Enterprise-level customers often have complex integration requirements both on and off platform; typically, Salesforce utilizes the SOAP and REST technologies to make these APIs available to any number of platforms and languages such as Java and Microsoft .NET. In Chapter 9, Providing Integration and Extensibility, we will discuss how you can extend the features of the platform data-orientated APIs with your own more application process-orientated APIs.
Tip
Note that not all platform APIs have an Apex variant that can be called directly, though this does not necessarily mean that they cannot be used. Apex supports making outbound HTTP callouts either via a WSDL or by directly creating and parsing the required requests and responses. A good example of this is the Metadata API, which can be used to develop Visualforce wizards to automate common setup tasks via Apex, as shown in an Apex example Ok to delete later in this chapter.
The following list details some of the main APIs that may be of use to your Enterprise-level customers wishing to develop solutions around your application:
- Enterprise API: This SOAP API is dynamically generated based on the objects present at the time in the subscriber org, meaning that any tool (such as data-mapping tools) or developer consuming it will find the information it exposes more familiar and easier to access. One downside, however, is that this can end up being quite a large API to work with, as Enterprise customer orgs often have hundreds of objects and fields in them.
- Partner API: This is also a SOAP API; unlike the Enterprise API, it provides a more generic CRUD-based API to access the record in the subscriber org. Its name can be a bit misleading, as there is no restriction to non-partners using it, and as it is lighter than the Enterprise API, it's often a first choice.
- REST API: This provides another CRUD style API, similar to the Partner API, but in this case, it is based on the more popular REST technology standard. It's often preferred when building mobile applications and is also fast becoming popular as the default API for Java and .NET.
- Metadata API and Tooling API: These SOAP APIs provide a means to automate many of the tasks performed under the Setup menu and those performed by developers when editing code. While these might not be of direct interest to those integrating with your application, as many of these tasks are performed initially and then only rarely, it might be something to consider using in tools you want to provide to keep the implementation times for your application low.
- Streaming API: This API utilizes a HTTP long polling protocol known as the Bayeux protocol to allow callers to monitor in near real time and record activity in Salesforce. This API can be used on a page to monitor race data as it arrives and display it in near real time to the user.
- Replication API: Sometimes it is not possible or desirable to migrate all data into Salesforce through Custom Objects. In some cases, this migration is too complex or cost prohibitive. This REST and Apex API allows replication solutions to determine for a given period of time which records for a given object have been created, updated, or deleted.
- Bulk API: This REST-based API allows the import and export of large amounts of records in CSV or XML format up to 10 MB in size per batch job.
The following are some considerations to ensure that your application objects are well placed to work well with OK platform APIs:
- Naming Custom Objects and fields: When naming your Custom Objects and fields, pay attention to API Name (or Developer Name, as it is sometimes referenced). This is the name used when referencing the object or field in the APIs and Apex code mentioned in the previous section. Personally, I prefer to remove the underscore characters that the Salesforce Setup UIs automatically place in the default API names when you tap out of the Label field, as doing so makes the API name shorter and easier to type with fewer underscore characters. It then ends up reflecting the camel case used by most APIs, for example,
RaceData__cinstead ofRace_Data__c. - Label and API name consistency: While it is possible to rename the label of a custom field between releases of your application, you cannot rename the API name. Try to avoid doing so, as causing an inconsistency between the field label and API name makes it harder for business users and developers to work together and locate the correct fields.
- Naming Relationships: Whenever you define Master-Detail or Lookup Relationship, the platform uses the plural label value of the object to form a relationship API name. This API name is used when querying related records as part of a subquery, for example,
select Id, Name, (select Id, Name from Races) from Season__c. When creating relationship fields, pay attention to the default value entered into the Child Relationship Name field, removing underscores if desired and checking whether the names make sense.For example, if you create a lookup field to the
Driver__cobject called Fastest Lap By on theRace__cobject, the default relationship API name will be Races. When using this in a subquery context, it will look likeselect Id, Name, (select Id, Name from Races) from Race__c. However, by naming the relationshipFastestLaps, this results in a more self-describing query:select Id, Name, (select Id, Name from FastestLaps) from Race__c. - Apex Triggers bulkification and performance: When testing Apex Triggers, ensure that you accommodate up to 200 records; this is the default chunk size that Salesforce recommends when utilizing its bulk APIs. This tests the standard guidelines around bulkification best practices; although smaller chunk sizes can be configured, it will typically reduce the execution time of the overall process. Also related to execution time is the time spent within Apex Trigger code, when users solely update fields that have been added in the subscriber org. In these cases, executing the Apex Trigger logic is mostly redundant, as none of the fields this logic is interested in will have changed. Therefore, encourage the optimization of the Apex Trigger logic to execute expensive operations (such as the execution of SOQL) only if fields that have been packaged have changed.