#Issue29
3 posts

Making fast APIs: lessons learned from 40 years of SQL

Give consumers full access over what to fetch, and don’t tie them to pre-determined data fields. Emulate SQL’s EXPLAIN method & let users know how exactly the database will execute their query.
Read more

Making fast APIs: lessons learned from 40 years of SQL

  • Give consumers full access over what to fetch, and don’t tie them to pre-determined data fields.
  • Emulate SQL’s EXPLAIN method & let users know how exactly the database will execute their query. Then they can see what may be slowing things down and correct it themselves.
  • If impossible to offer full access, optimize your API for common access patterns.
  • Make it easy for users to fetch all the data they need in one go, rather than looping multiple requests.
  • Design the API to cache data locally.
  • Design the API to study access logs and prefetch relevant data accordingly as this impacts the perceived speed of fetching without changing throughput.
  • Learnings from the NoSQL movement: model data structure on data access patterns; and that users want consistency more than the fastest (or the slowest) speeds possible.

Full post here, 10 mins read

You can’t protect what you can’t see

Establish visibility so that the business knows what is exposed and how, to whom, through the API. Authenticate both end-users and client applications. OAuth2 is the de facto standard.
Read more

You can’t protect what you can’t see

A few ways to secure APIs:

  • Establish visibility so that the business knows what is exposed and how, to whom, through the API. An API management layer should have monitoring and analytics capabilities to detect threats in real-time.
  • Authenticate both end-users and client applications. OAuth2 is the de facto standard.
  • Validate all input so that it matches expected parameters—this protects your API against SQL injections, cross-site scripting & other common threats. It also acts as an early-warning system when scouts explore APIs for vulnerability.
  • Secondary to ensuring your infrastructure can scale out to avoid a DDoS attack, rate limits within the API can check for attacks and avert minor traffic spikes.
  • As a defense against bad bots, put the onus on the client to prove their identity - with reCAPTCHA, for example.

Full post here, 10 mins read

5 tips for wrapping your database with a REST API

Don’t let implementation details leak into your API. Use clear resource concept names. Don’t use abbreviations or naming conventions in URLs.
Read more

5 tips for wrapping your database with a REST API

  • Don’t let implementation details leak into your API. Use clear resource concept names. Don’t use abbreviations or naming conventions in URLs.
  • Paginate search results and limit the number of pages returned and to cap the maximum number of records per request. Add hypermedia links to first, last, next & previous pages for easy navigation.
  • Stick to the standard response codes, don’t invent new ones. Use the common HTTP response codes 200, 201, 204, 400 and 404.
  • When data arrives from a client, always validate required fields, field types, & formats. Never passing SQL in the URL.
  • Add workflow-based functionality to APIs so that they go beyond mere data access.

Full post here, 6 mins read