Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

BigCommerce API

No description
by

Ray Ward

on 16 August 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of BigCommerce API

BigCommerce API Customer, Orders and Products
Read only
XML only
Unmaintained
Limited usefulness
No versioning. Completely RESTful API
Supports all CRUD actions through HTTP methods
GET (read), POST (create), PUT (update), DELETE
Authenticates using HTTP Basic Access.
JSON and XML input and output.
Data validation
Versioning
Throttling and logging
12,710 lines of code
110 unit tests and counting! XML API REST Representational State Transfer
Stateless (no client context stored on server)
Takes advantage of built-in HTTP features, such as errors responses and caching
Resources are identified by their URI (eg. /orders/5/products/6.xml
HTTP request methods (eg. GET, POST) interact with the resource
Easier to scale Authentication Basic Access Authentication supported
Simply base 64 encoded admin:password sent as a HTTP header
API token is used as the password
Current user permissions used to control access to resources
Digest Access Authentication or OAuth implemented in future Data Formats JSON and XML supported for input and output
Input parsing and output encoding is abstracted to allow additional formats to be added
Client specifies response data type as either extension (.xml) or Accept header (Accept: application/xml)
Client specifies posted data type in Content-Type header (Content-Type: application/json) HTTP Response Codes Many different types of HTTP responses utilised
Response codes indicate success or failure of request
Some failures include a message and other details in the response
2xx for success
3xx for redirection
4xx for client errors
5xx for server errors Data Validation Resources specify the fields that they will return and accept
The fields specify their accepted data type (integer, string etc) and length (if applicable)
This allows automatic validation of input data and reduces repetition of code
Fields can also be tied directly to a database field for automatic filtering, specified as read only and if they allow nulls
Additional validators can be added to fields for futher validation (eg. date, order status, country codes) Features For Future Releases Content encoding (eg. gzip) for smaller transfers
Etag support for better cache control
More authentication methods
More CRUD methods on existing resources
Add additional resources Versioning Allows implementation of new features or changes that would normally break backwards compatibility
Heirarchical structure allows the API to search from top to bottom through versions to find a resource or method
Avoids having to replicate implementations of resources or methods that haven't changed between versions
Versions can be marked as deprecated Routing Overview Sample request: /api/v1/orders/5/products/6.json
Request enters application like any other request to the store
The dispatching system sees that the URI contains the segment /api/ and sends the request through the API router: 1. The router breaks the path down into segments that allows validation of individual parts such as the version, resource path and the data type
2. The data type for the response is determined from either the Accept header, or file extension
3. Numbers in the URI (eg entities) are extracted out and converted them into paramaters
4. The path along with the request method (eg. POST) and the version are then used to discover a class: Store_Api_Version_1_Resource_Orders_Products
5. This above information is then assigned to a Route object
6. The route checks if the API has been throttled
7. The route then executes the request on the API which calls the specified method on the class: Store_Api_Version_1_Resource_Orders_Products->postAction()
8. If the request was succesfull, the Route is cached so that future requests can skip the discovery and validation process.
9. Any errors along through the entire process throw an exception which is captured and converted into a HTTP response with error details. Throttling The API can throttle the amount of requests
Throttling is based on the amount of requests made in the last 60 minutes
The amount of allowed requests is determined by the plan the store is on
The amount of requests remaining is indicated by a header in the response 'X-BC-ApiLimit-Remaining'
If the API is throttled a 509 Bandwidth Limit Exceeded response is sent
PUT/POST requests only allow updating or creating one entity at a time. Logging Requests to the API are logged
Each log entry contains the date, user id, version, resource, method, query string, user agent, response status, request count
Used by the throttling system
Request log can be accessed via the /requestlog resource potentially useful for support, debugging, stats Other Features Paging and limiting of responses
HEAD and OPTIONS methods supported
HEAD performs a GET request but returns no body.
OPTIONS checks which methods are available for a resource and returns them in the Allow header
Full transcript