Skip to content

Instantly share code, notes, and snippets.

@AlexAtkinson
Last active June 6, 2023 23:56
Show Gist options
  • Save AlexAtkinson/9749eda071841f18931bafd7070e43f4 to your computer and use it in GitHub Desktop.
Save AlexAtkinson/9749eda071841f18931bafd7070e43f4 to your computer and use it in GitHub Desktop.
API Design Tips for beginners and professionals alike.

API Design Tips

DO: Start by Understanding APIGW

APIGW is NOT the AWS service, but an industry standard technology for servicing resource access while providing facilities for oversight, governance, security, and operability considerations.

Some options:

  • Apache APISIX
    • Free, but you still pay for your own wrench time.
  • Kong
    • The GW is open source and free to use, but many features (such as OIDC) are paywalled.
    • Kong is pretty much the defacto industry standard, and offers a fantastic product ecosystem.
  • Tyk
    • Paid
  • KrakenD
    • Many features are included in the open source product, but some plugins are paywalled.
  • Gravitee
    • Paid

DO: Start With the Diagram and Docs

Draw a diagram. Write the docs. Include traffic flows, methods, protocols, etc. If you can't do these things, how can you even start writing code? This exercise is useful as you not only get these assets early, but often identify issues before you've invested in a body of tech debt behind them.

DO: Include Version URL Component (ie: /v1/, /v2/)

to decouple and enable your api development without affecting existing users.

DO: Use HTTP Methods to Inform Action

This greatly mitigates API complexity. Why bloat the body of the payload including action flags when the method is suffficient.

For inspiration, look to Mesosphere's Maraton API docs.

DO: Mitigate Endpoints Sprawl Early

Collapse interactions into as few concise and meaningful endpoints as possible. For example, if you have an endpoint that handles a configuration, have one endpoint such as '/configuration', and have it handle all CRUD activities, instead of having multiple endpoints.

DON'T: Over-think API Interactions or Logic

If something seems complicated or confusing, you're probably doing it wrong. Go for a coffee, then look at the defined service boundaries again.

DO: Align the frontend and API (if applicable)

Similar to magic numbers in code, it is undesirable to have mysterious or convoluted functions or workflows in one that aren't clearly defined in the other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment