DEV Community: James Bowes

Strategies for Asynchronous APIs

James Bowes — Sat, 17 Apr 2021 20:57:24 +0000

Most APIs will require some form of non-blocking or asynchronous mechanisms for specific endpoints. It could be an import task that takes minutes or hours, report generation, or even deleting a resource. In any case, whatever the caller is asking for can't be done immediately, but the caller would like to know when its done (for example, so a user can view the report) and may like to know about progress (for example, so they can show import task status in a UI). If you're lucky, you'll catch most of these at the start, though inevitably some change in requirements, features, or performance characteristics will require changing an API from blocking or non-blocking.

Required machinery

If a given API endpoint must be asynchronous, you can assume the work it has to do will take longer than a single HTTP request. Further, if the work will take longer than a single HTTP request, you can assume it will take longer than the lifetime of your server process.

You'll need to decouple the work from HTTP requests (say, with a background worker process or thread), and make the work durable and resilient to process crashes / restarts (with task queues, etc). With care, you can make these changes before modifying existing public APIs or introducing new ones.

Strategies

Pretend and defer

Pretending that the API is still synchronous, and deferring expensive work, is often the best option for retrofitting existing APIs. If your API continues to pretend the action is synchronous, you can keep the same interface.

This strategy works best for actions that can tolerate eventual consistency in some of their data, or for actions that can mitigate inconsistency via other means.

Pretend and defer is often applied to user / account deletion. An account deletion may require cascading deletes to all owned data in the same service, calls to other services to delete owned data, calls to third party services to remove records of the account, and possibly some time-delayed actions to perform accounting at the end of a billing period.

Instead of blocking and waiting for all this work to complete, an account deletion API can mark the account as disabled and revoke any authentication tokens, effectively making the account inaccessible. Any expensive work is then done later on, either via direct work scheduling from the API, or through bulk cleanup processes.

Block and de-duplicate

For cases where an existing API endpoint's work can't be deferred, you can maintain the existing API (until it's been removed via a deprecation policy), run the work in a background task, and de-duplicate requests via idempotency.

Treat each HTTP request as a request to enqueue background work, keeping the request open. Have the server poll the background worker on behalf of the client, returning a response when the background work is done. Use idempotency (likely based on the contents of the request) to de-duplicate in-flight requests, pointing them all at the same in-process background work.

If the long-running work completes before the client times out (or the server crashes, etc), then from the client's perspective, the API has not changed. If the client times out, and retries, then idempotency assures that the client resumes tracking the same original work. If the client does not retry, then the work will complete, regardless.

Resources with status

While the first two strategies are half-steps meant to support backwards compatibility, adding a status field to a resource is a cleaner, more complete solution, that may also break backwards compatibility.

In this strategy, any API request to create a resource creates it right away, filling in as many details as possible, with the addition of a status field, which records state transitions as the resource progresses from an accepted request, to a completed and created resource.

For example, consider creating a new Cat Bonnet that is hand sewn on demand:

POST /v1/cat-bonnets HTTP/1.1
Content-Type: application/json

{
  "name": "red bonnet"
}

HTTP/1.1 201 Created
Location: /v1/cat-bonnets/3f566245-754a-44af-82fd-b754d4b03fb6
Content-Language: en-CA
Content-Type: application/json

{
  "id": "3f566245-754a-44af-82fd-b754d4b03fb6",
  "name": "red bonnet",
  "status": [
    {
      "state": "accepted",
      "time": "2021-04-08T07:22:03Z",
      "description": "Your bonnet has been accepted for processing."
    }
  ]
}

The POST response returns the pending Cat Bonnet resource. The client can then poll the server, watching the state of the Cat Bonnet:

GET /v1/cat-bonnets/3f566245-754a-44af-82fd-b754d4b03fb6 HTTP/1.1

HTTP/1.1 200 OK
Content-Language: en-CA
Content-Type: application/json

{
  "id": "3f566245-754a-44af-82fd-b754d4b03fb6",
  "name": "red bonnet",
  "status": [
    {
      "state": "sewing",
      "time": "2021-04-08T07:23:49Z",
      "description": "Expert craftspersons are sewing your new bonnet."
    },
    {
      "state": "accepted",
      "time": "2021-04-08T07:22:03Z",
      "description": "Your bonnet has been accepted for processing."
    }
  ]
}

Eventually, the Cat Bonnet will be fully sewn and complete. Hooray!

As in the above example, status may exist directly on a resource that has meaning for end users. It may also exist on a resource that is mostly meaningful for the long-running task itself, but also has use as a record or log, like an Import type.

For resource modification or DELETEs, the resource proper can stay in its old state, until the status progresses to the point where the modification is complete.

Note that this is similar to, but not the same as, Kubernetes' status field, which fully describes the current state of a resource and optionally may include fields describing the resource's state transition history.

For additional context, the IBM Watson REST API Guidelines have additional details on a similar style of asynchronous API.

Job specific indirect resources

A job specific indirect resource has a few differences from putting status on a resource:

The job specific resource is often a generic type, like Job, Operation, or similar.
Its lifetime may be short, say only 24 hours after task completion or failure.
They are often created indirectly at the server's discretion.

The last point can be powerful; it gives the server the option of responding immediately, or giving the client a URL to use for polling results, making this decision at runtime.

Expanding on the Cat Bonnet creation example above, given the following request:

POST /v1/cat-bonnets HTTP/1.1
Content-Type: application/json

{
  "name": "red bonnet",
  "fabric": "purest unicorn mane"
}

The server could reference warehouse stock for purest unicorn mane to determine if the Cat Bonnet could be fabricated in a reasonable amount of time, or if there is no stock, and fabricating the bonnet may require an asynchronous response.

Direct response

If there is stock, the server can create the bonnet and respond immediately:

HTTP/1.1 201 Created
Location: /v1/cat-bonnets/3f566245-754a-44af-82fd-b754d4b03fb6
Content-Language: en-CA
Content-Type: application/json

{
  "id": "3f566245-754a-44af-82fd-b754d4b03fb6",
  "name": "red bonnet"
}

Indirect response

If, on the other hand, there is no stock, the server can respond with a 202 Accepted and point the client at an endpoint for polling status:

HTTP/1.1 202 Accepted
Location: /v1/jobs/27440252-c84a-40aa-8a17-8c3532eb8aca
Content-Language: en-CA
Content-Type: application/json

{
  "description": "Cat Bonnet creation accepted",
  "status_id": "27440252-c84a-40aa-8a17-8c3532eb8aca"
}

Note that 202 Accepted is intentionally non-committal and vaguely defined. Further, Location has no defined meaning when used with it. However, convention in APIs has landed on using the two together for non-blocking APIs.

The client can then make repeated requests to the /v1/jobs endpoint returned in the Location header to get the status of the Cat Bonnet creation.

GET /v1/jobs/27440252-c84a-40aa-8a17-8c3532eb8aca HTTP/1.1

HTTP/1.1 200 OK
Content-Language: en-CA
Content-Type: application/json

{
  "id": "27440252-c84a-40aa-8a17-8c3532eb8aca",
  "status": [
    {
      "state": "sewing",
      "time": "2021-04-08T09:15:49Z",
      "description": "Expert craftspersons are sewing your new bonnet."
    },
    {
      "state": "accepted",
      "time": "2021-04-08T07:22:03Z",
      "description": "Your bonnet has been accepted for processing."
    }
  ]
}

Once done creating the Cat Bonnet, the server can reply with an updated status including information on where to find the created Cat Bonnet. It's also acceptable and common to return a 201 Created response with a Location header:

HTTP/1.1 201 Created
Location: /v1/cat-bonnets/3f566245-754a-44af-82fd-b754d4b03fb6
Content-Language: en-CA
Content-Type: application/json

{
  "id": "27440252-c84a-40aa-8a17-8c3532eb8aca",
  "status": [
    {
      "state": "created",
      "time": "2021-04-08T09:15:49Z",
      "description": "Your new bonnet is ready.",
      "bonnet_id": "3f566245-754a-44af-82fd-b754d4b03fb6"
    },
    {
      "state": "sewing",
      "time": "2021-04-08T09:15:49Z",
      "description": "Expert craftspersons are sewing your new bonnet."
    },
    {
      "state": "accepted",
      "time": "2021-04-08T07:22:03Z",
      "description": "Your bonnet has been accepted for processing."
    }
  ]
}

It's OK to reply with a 201 Created after the Cat Bonnet is created, but it isn't OK to respond with a 4XX series status code on error. A 4XX series code should be served in response to the direct request for the job status only (for example, if the client asked for a job ID that didn't exist).

Flexibility is complexity

Every client will have to know how to handle a direct response and an indirect non-blocking response. Take this into account; it may be better to always return a 202 Accepted response, even for fast replies.

Picking a style

Most often the style of asynchronous API you choose is influenced by existing APIs, data, schema, etc. If you're mostly free from those constraints, your choices are likely between:

status on end-user meaningful resources (for example directly on Cat Bonnets)
status on job-specific indirect resources (for example creating a Job to track sewing a new Cat Bonnet)

Both of these styles can handle asynchronous resource creation, modification, or deletion, whereas direct creation of a job-specific resource like an Import may complicate your API for modification or deletion. An import resource can be useful to track when a single entity was imported into a system, but pairing it with a Deletion resource, or placing long-running delete status directly on the imported entity makes less sense.

Given the two options then, your choice should be influenced by how useful the status data is, and how badly a client can break their application by ignoring the data.

At Manifold, our API had both styles of API for creating (buying) a resource (SaaS DB) over the years.

We began with job-specific resources. These were problematic for display in the frontend UI; the client was responsible for merging the list of real resources with the ones that were in the middle of creation, plus modifying the real ones for any in-flight change or delete jobs. Performing this merge was extra work for the frontend client, and error prone. We would end up with out of order lists, or missing in-creation resources, or duplicate entries for the real resource plus its modification job.

Changing the API to have status directly on resources made the client simpler. Even if the client ignored the status field, the list of resources would always be correct, only misidentifying in-creation resources as live ones. If that bug ever occurred, further user interaction might fail, but it was far better to show the resource than miss displaying it.

So again, the best style for your API will depend on how you expect clients to consume it.

What goes in `status`?

The most useful status fields are arrays of objects like those shown in the examples above, sorted in newest to oldest:

[
  {
    "state": "accepted",
    "time": "2021-04-08T07:22:03Z",
    "description": "Your bonnet has been accepted for processing."
  }
]

A machine readable state field (which could terminate on completed or errored), coupled with a human-readable description field should give enough data for meaningful progress feedback. If you have it, you could add estimated time to completion, as well.

Be careful of too many possible state transitions; you don't want this array to grow to hundreds (or even tens) of entries. If that's possible, you may wish to truncate to the last N entries, instead of resorting to pagination.

If your data doesn't have meaningful state progressions, a percent_complete field can work just as well. Add it in addition to the state field, so state can indicate running, completed, or errored.

Variants

The above strategies require the client to make repeated requests to the server (polling) to get the latest state of a request. Polling is excellent for client simplicity and compatibility; if a client can make an HTTP request to start an asynchronous action, they can make further requests to get the status. However, polling adds additional work for your server to do, and will add some latency from when work is finished to when the client knows (depending on the polling interval). You may wish to support additional features to reduce latency for the client or load on your server.

Callback URLs

Callbacks are like targetted one-off webhooks. When a caller creates an asynchronous operation, they supply a callback url parameter that the server will call on completion. The caller then has less state to track, and no polling to do; it can wait for the callback to arrive on completion or error (though practically speaking it should not trust the server to callback, and implement its own timeout if required).

As the caller is providing an arbitrary URL, care should be taken to ensure the caller has some proof of ownership of that URL, and you may wish to sign the callback payloads to help protect the client from arbitrary callers or replay attacks.

As the callback needs a server to call back to, this option is best suited for APIs that will be called by other server-side processes. Not only will the calling server not have to maintain a long-running session to poll for status (tricky when we expect systems to crash and go away all the time), but the calling server may not have to maintain much additional state, provided the callback response contains enough context.

Push on state change

Instead of requiring the client to make new requests for status periodically, they can instead open a long-lived connection with WebSockets or Server-Sent Events, allowing the server to push state changes to them, as they happen. Push-based APIs such as these require your infrastructure to take on an additional level of state, tracking who has subscriptions to what, across your fleet of servers. It can be deceptively difficult to set up, and support may vary across different infrastructure providers and technologies.

Pushing on state change is most applicable to clients that maintain sessions and state, like web browsers or mobile apps.

One-Sided Idempotence

James Bowes — Sun, 04 Apr 2021 13:09:57 +0000

In the last post, we discussed the idempotency-key header, and how this header can be used to add idempotence to otherwise non-idempotent HTTP methods (like POST) in REST APIs. We also touched on how many HTTP methods are inherently idempotent, like DELETE. But just how idempotent is it, in practice?

To recap, DELETE is an idempotent HTTP method because after the first request to delete a resource, a client can make any number of subsequent duplicate DELETE requests, and the resource will stay deleted. The end state on the server side stays the same, no matter how many DELETE requests it sees. Idempotent requests like DELETE have another interesting property: After that first request, failures, errors, and malformed or misinterpreted requests maintain the same state on the server side. Side note: If you've ever seen a bug that caused a resource to be re-created on a failed delete, let me know on twitter. I'd love to hear about it.

"server side" is important here. Discussion of idempotence usually focuses on the server (or whoever holds the canonical state), glossing over its impact on the client; it's a one-sided view. The client is important too, particularly in distributed systems, where "the client" might be one of many hops between the server and a user.

Idempotence, when paired with retries, provides resilience against failures in the network, etc. If a wire is tripped over when the server is responding 2XX to a DELETE, but before the client reads that response (and the client eventually times out), then at some point, the client will retry the request. How the server responds to that second request will impact the complexity of the client's logic for handling replies, and may ultimately end up impacting what an end user sees.

For a real-world example of how responses from idempotent requests can impact clients, let's look at an example using Stripe. Stripe's API makes ample use of idempotence, and is typical in how it handles DELETE requests. First, assume we have the following product defined:

GET /v1/products/prod_JEbKPQJxRVglrR HTTP/1.1
Host: api.stripe.com

HTTP/1.1 200 OK
Content-Length: 430
Content-Type: application/json

{
  "id": "prod_JEbKPQJxRVglrR",
  "object": "product",
  "active": true,
  "attributes": [

  ],
  "created": 1617451149,
  "description": "A premium hobby-grade cat bonnet.",
  "images": [

  ],
  "livemode": false,
  "metadata": {
  },
  "name": "Cat Bonnet",
  "package_dimensions": null,
  "shippable": null,
  "statement_descriptor": null,
  "type": "service",
  "unit_label": null,
  "updated": 1617451217,
  "url": null
}

This product is a hobby-grade cat bonnet for sale in our online cat bonnet marketplace, listed by an independent cat bonnet artisan. Imagine the artisan decides to stop selling this particular cat bonnet. Their pressing of a delete button in the UI triggers the following call in the cat bonnet marketplace:

DELETE /v1/products/prod_JEbKPQJxRVglrR HTTP/1.1
Host: api.stripe.com

HTTP/1.1 200 OK
Content-Length: 76
Content-Type: application/json

{
  "id": "prod_JEbKPQJxRVglrR",
  "object": "product",
  "deleted": true
}

The 200 response indicates success, and the response is a sparse representation of the deleted product. Note that while the Stripe docs on products say the product is returned, the only data we get is values we could infer from the request itself.

Now, imagine if the backend server never saw that 200 response, and retried its request to delete. This is the response it would get:

DELETE /v1/products/prod_JEbKPQJxRVglrR HTTP/1.1
Host: api.stripe.com

HTTP/1.1 404 Not Found
Content-Length: 236
Content-Type: application/json

{
  "error": {
    "code": "resource_missing",
    "doc_url": "https://stripe.com/docs/error-codes/resource-missing",
    "message": "No such product: 'prod_JEbKPQJxRVglrR'",
    "param": "id",
    "type": "invalid_request_error"
  }
}

A 404, indicating (since it's a 4XX series response) that the client made a mistake, and this resource doesn't exist. The end result from Stripe's perspective is still that the product is deleted, but now, unless the cat bonnet marketplace backend accounts for a 404 response status, and the difference in the response bodies, the end user may see an error message instead of success.

In the case of Stripe, the API is responding to to the requested change and not responding to the desired state (this is similar to [edge vs level triggering edgevlevel). If the API treats a DELETE as "ensure this resource does not exist" instead of "delete this existing resource", then so long as the resource does not exist at the end of a DELETE request, the server can respond with a 200 OK, the client will know that the resource doesn't exist (as it desired), and the client doesn't require any additional logic for treating 404 responses as successes.

Back to Stripe's original 200 response: It's documented as returning the deleted object, but only returns the object type and id (both of which are included in the DELETE request). Many APIs do return the full deleted object. Be careful with this when designing APIs; you'd make extra work for yourself trying to return the deleted object for multiple delete requests.

Sometimes, it matters to the client if the resource being deleted actually was deleted by them or not. In those cases, you could either encourage the client to GET the resource first, and see if it exists (ignoring a possible race condition), or include an additional response header or field on the body indicating if that request caused a delete.

Designing APIs requires balancing tradeoffs, predicting common usage patterns, and aiming for simplicity. Next time you implement DELETE, consider if always returning 200 may be best. But be careful to not introduce inconsistencies with other DELETE endpoints in an existing API.

What is the idempotency-key header?

James Bowes — Sat, 27 Mar 2021 10:12:21 +0000

In Computer Science (and in its cooler older sibling, Mathematics) idempotence is a property of an action (e.g. an API call) such that doing the action again with the same inputs produces the same result. In the context of HTTP, a GET request is usually idempotent; making a request to the same URL should return the same response, and not change any relevant data in the backing data store. A DELETE request is likewise typically idempotent; no matter how many times you DELETE a given URL, the resource stays deleted after the first call, no other resources are deleted, etc.

Idempotence is a great property for APIs to have. Idempotence coupled with retries can mitigate many problems related to the unreliability of networks, computers, and software. If any request along the chain between the client and your data store fails, the downstream initiator can safely retry. Even impatient users frantically clicking buttons and refreshing pages are no match for idempotence!

Looking at the HTTP methods used in REST APIs, some are inherently idempotent, and others are not:

GET: Show me the thing I asked for. IDEMPOTENT
DELETE: Ensure the thing I referenced does not exist. IDEMPOTENT
PUT: Ensure the thing I gave you exists exactly as I gave it to you. IDEMPOTENT
PATCH: Apply the provided set of changes to the current state of the thing I referenced. NOT IDEMPOTENT
POST: Create this thing I gave you (usually at a different URL), or modify a thing based on inputs and its current state. NOT IDEMPOTENT

POST and PATCH are not idempotent. PATCH is especially resistant to being made idempotent, as a PATCH operation is meant to apply context-aware changes to a resource in its current state. Applying the same change multiple times, as the resource's state is updated, will at best result in an error, and at worst result in a new state that the caller didn't intend. Strategies like optimistic concurrency control are often best for PATCH.

POST, on the other hand, can be made idempotent - particularly for uses meant to create a resource. If we're building an API to sell Cat Bonnets, POST requests to create new store listings could include the bonnet size and color as the most important and meaningful fields. A content-aware idempotence scheme would treat any POSTs with the same size and color as intention to ensure such a listing exists. As long as one already does, the POST won't create a new one; N > 1 requests to create a large blue bonnet always result in only 1 large blue bonnet existing.

The idempotency-key header is another way to bring idempotence to non-idempotent HTTP methods (particularly POST). The caller can supply a unique value for the header. If the header is supplied, then the server returns the same response for any requests with the same value for idempotency-key (usually within a 24 hour window; we can't expect infinite storage). But if we can make a POST idempotent based on the request contents, what's the use of this header?

A hint lies in companies that implement it: [Stripe stripe, Square, and Twilio (to name a few).

These are companies that provide APIs interacting with the outside world, where each action is expensive (sometimes in real money), and the expense compounds with duplicates (e.g. charging a user twice for the same good also damages reputation).

An SMS API wants to let its clients send a message to user X with message body "you have a new notification" more than once, maybe within minutes or seconds of each other, or even at the same time. Further, they also want to allow the clients to have a means to prevent duplicate sends if from the client's point of view, there is only one message. Doing this with content-based idempotence would require additional significant fields in the request body, ultimately boiling down to a unique key - essentially identical to the idempotency-key header. Putting the field in an HTTP header allows for easier reuse between API endpoints, and keeps values out of the schema that aren't directly meaningful for the problem space.

Ignoring any imposed expiration on idempotency-key values, adding the header to POST requests makes them look a lot like PUTs: The unique value a client uses for idempotency-key maps to the URL (typically including a unique ID in the path) that they would call PUT on. There are a few reasons why a PUT may not make sense for an API:

You may want full control over your resource IDs and their URLS; letting a client provide them in PUTs would give that control up.
The scheme for your IDs is complex enough that expecting clients to create them is unreasonable; letting them provide arbitrary idempotency-key values is easier.
You don't want to persist any of the request resources. PUTing wouldn't make sense, as the resource won't exist at the URL after the operation is finished.

As a final note, this post is not idempotent. Repeated readings may further enhance your understanding of idempotence for APIs.

Modern webhook signatures in 2021

James Bowes — Fri, 26 Mar 2021 13:37:10 +0000

This post is a follow-up to the previous post on x-hub-signature

It's 2021, and you work for Cat Bonnets Online. The bigwigs up on the top floor just finished telling you over Zoom that the company is modernizing its strategy. While half the company is converting the bonnets to NFTs (Nice Feline Toppings), and the rest is working on a Clubhouse strategy, your team is adding webhooks.

You want to sign your webhooks, so receivers can verify you sent them. Don't use x-hub-signature for this. It's not good enough, and there's a better option in 2021: [The "Signing HTTP Messages" draft specification httpsig. This new specification addresses three shortcomings in x-hub-signature:

Headers can be included in the signature: If your webhook includes important information in headers (for example, event or account identifiers), it should be signed, so the receiver can ensure they haven't been tampered with.

There's a facility for expiration: Sent requests can have an expiration time, mitigating replay attacks. If your events are not idempotent (or the receiver doesn't treat them as such) a bad actor could intercept a request, and repeatedly send it to the reciever. This could lead to resource exhaustion, lost data, or inconsistent state.

Asymmetric keys are supported: x-hub-signature implementations use symmetric keys for signing and verification. While this is faster than asymmetric forms, it means a bad actor could steal the key from your system, from the receiver, or while it's in transit between the two during setup. With asymmetric keys, you only need worry about having the key stolen from your own system.

The first two issues with x-hub-signature (unsigned headers and no expiration) can be solved in a layer above the signature, by including all details only in the message body, and having an application defined expiration. It's too easy to let important data slip into the headers over time, or for a receiver to not implement the extra step of checking the expiration time. Why not let a specification (and hopefully a standard library) handle it for you and your receivers?

At Manifold, we implemented request signing based on an earlier version of the spec, but modified to address some shortcomings in the spec at the time (notably that while header contents were included in the signature, the header names were not). You can read about that implementation, and see code samples, on Manifold's request signing documentation. We deviated from the spec at the time, but now, you don't have to.

What is x-hub-signature?

James Bowes — Fri, 26 Mar 2021 10:30:42 +0000

TL;DR x-hub-signature is an HTTP body only signing scheme from the WebSub standard.

Webhooks are a common way on the modern web for one application to send events to another, in a way that doesn't tightly couple the first application to the second. For example: Application one (henceforth "Cat Bonnets Online") is configured by a customer at runtime to send events to application two (henceforce "Chat App"). Cat Bonnets Online sends events in its own format to the configured endpoint of Chat App. Chat App knows it gets webhook events from Cat Bonnets Online, and knows how to parse and display them. Cat Bonnets Online knows nothing about Chat App, other than that it is another endpoint that receives webhook events.

Chat App now has a public-facing URL that, when called, displays information from the received event to all users of a given Chat App instance. That's great when those users want to know if someone bought them the latest argyle cat bonnet. It's not so great when a bad actor discovers and calls the endpoint with hateful and abusive content.

Webhooks need SECURITY! x-hub-signature is a header containing an HMAC signature of the body of the webhook request. During webhook configuration, Cat Bonnets Online and Chat App share a secret. This secret is used in the HMAC, allowing Chat App to verify that all webhooks it receives have this header, and that the HMAC is correct, assuring webhooks come from Cat Bonnets Online.

x-hub-signature is used by lots of applications that send webhooks (GitHub, Facebook, etc), but without reference to where it comes from: the WebSub standard (Formerly known as PubSubHubBub). Knowing the connection can help answer questions like "Why does Facebook do a verification request with all these hub.XXX parameters?" or "Is hub short for GitHub?", and help find the subtle differences between each implementation.

It's too difficult to find the connection between x-hub signature and WebSub. Hopefully this post will help the search rankings of WebSub, even just a tiny bit. Spread the word!

Now that you know what x-hub-signature is, you should never use it for a new webhook implementation in 2021. Read this follow-up post to learn about what you should use instead.