Usage Guidelines. salesforce.com API

PDF

Dokument

AppExchange API

HAPTER

U s a g e G u i d e l i n e s

This topic describes usage guidelines and best practices for developers using the API. It contains the following sections:

•

Content Type Requirement

•

Request Metering

•

Compression

•

HTTP Persistent Connections

•

HTTP Chunking

C

ONTENT

T

YPE

R

EQUIREMENT

In the API version 7.0 and later, all requests must contain a correct content type, for example:

Content-Type: text/xml; charset=utf-8

. Earlier versions of the API do not enforce this requirement.

R

EQUEST

M

ETERING

To maintain optimum performance and ensure that the API is available to all of our customers, salesforce.com balances transaction loads by limiting the number of API requests (or calls) that any one customer organization may execute concurrently or within any 24-hour period. The limits are based on edition type, as specified in the following table:

Edition Types

Developer Edition

• Enterprise Edition

• Professional Edition

(with API access enabled)

Unlimited Edition

Limits

5,000 calls per organization per 24-hour period, or

5 concurrent calls at any one time

1,000 calls per license per 24-hour period, or

1,000,000 calls per organization per 24-hour period, whichever is lowest

5,000 calls per license per 24-hour period, or

5,000,000 calls per organization per 24-hour period, whichever is lowest

When an organization exceeds any limit, the organization may be temporarily blocked from making additional calls until the end of the relevant 24-hour period.

C

OMPRESSION

The API allows the use of compression on the request and the response, using the standards defined by the HTTP 1.1 specification. This is automatically supported by some SOAP/WSDL clients, and can be manually added to others. Visit http://www.salesforce.com/developer/ projects_toolkits.jsp

for more information on particular clients.

Compression is not used unless the client specifically indicates that it supports compression. For better performance, we suggest that clients accept and support compression as defined by the

HTTP 1.1 specification.

Page 29

AppExchange API

To indicate that the client supports compression, you should include the HTTP header “Accept-

Encoding: gzip, deflate” or a similar heading. The API compresses the response if the client properly specifies this header. The response includes the header “Content-Encoding: deflate” or

“Content-Encoding: gzip,” as appropriate. You can also compress any request by including a

“Content-Encoding: deflate” or “gzip” header.

Most clients are partially constrained by their network connection, even on a corporate LAN.

The API allows the use of compression to improve performance. Almost all clients can benefit from response compression, and many clients may benefit from compression of requests as well.

The API supports deflate and gzip compression according the HTTP 1.1 specification.

Response Compression

The API can optionally compress responses. Responses are compressed only if the client sends an Accept-Encoding header with either gzip or deflate compression specified. The API is not required to compress the response even if you have specified Accept-Encoding, but it normally does. If the API compresses the response, it also specifies a Content-Encoding header with the name of the compression algorithm used, either gzip or deflate.

Request Compression

Clients can also compress requests. The API decompresses any requests before processing. The client must send up a Content-Encoding HTTP header with the name of the appropriate compression algorithm. For more information, see:

• Content-Encoding at: www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.11

• Accept-Encoding at: www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3

• Content Codings at: www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5

Note

Details about how to implement request SOAP compression in Java with Apache Axis can be found in Tech Notes on the Salesforce.com Developer Web site: http://www.salesforce.com/ developer/tech-notes.jsp?tn=TN-14 h.

HTTP P

ERSISTENT

C

ONNECTIONS

Most clients achieve better performance if they use HTTP 1.1 persistent connection to reuse the socket connection for multiple requests. Persistent connections are normally handled by your

SOAP/WSDL client automatically. For more details, see the HTTP 1.1 specification at: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1