#api
33 posts

Tips on API monitoring

Track your functional uptime with comprehensive, end-to-end testing for both functionality and performance. Simple ping tests are usually not enough to meet your service level agreements (SLAs).
Read more

Tips on API monitoring

  • Track your functional uptime with comprehensive, end-to-end testing for both functionality and performance. Simple ping tests are usually not enough to meet your service level agreements (SLAs).
  • Since 95% of API vulnerabilities are due to human error, add monitoring at 5-minute intervals for breaches and downtime. Integrate automated testing into every step of your CI/CD pipeline to filter out human errors and make sure you have load-testing capabilities too.
  • But you should beware of

- tools that perform ‘synthetic testing’ and cannot reproduce actual consumer flows.

- tools that use third-party clouds, adding another layer of insecurity to your API (have internal APIs use on-premise tools instead).

- having separate testing and monitoring solutions.

- tests that are not detailed enough for intelligent results.

Full post here, 4 mins read

Indirect benefits of building API-first

A major benefit of building API-first is agility, both digital and strategic. You are not constrained to a single usage pattern and have the basis for a variety of applications with use cases you can’t even imagine yet, offering both flexibility and reusability.
Read more

Indirect benefits of building API-first

  • A major benefit of building API-first is agility, both digital and strategic. You are not constrained to a single usage pattern and have the basis for a variety of applications with use cases you can’t even imagine yet, offering both flexibility and reusability.
  • Your end-user has a better experience since APIs encourage interactivity across internal and external applications, creating a stickier, unified experience for consumers.
  • Building your organization around APIs creates a potential for partnerships, big and small, whether using the marketplace model (your platform allows others to build and distribute custom add-ons, in turn extending your own platform) or one where partner APIs share data with a common, collaborative goal.
  • Outward-facing APIs enable the growth and inception of self-sustaining developer communities, providing you with awareness, API support, product suggestions and more.

Full post here, 4 mins read

The API security maturity model

The API Security Maturity Model is a corollary to the Richardson Maturity Model associated with RESTful API design, describing four levels of REST compliance. It describes cumulative levels of security, complexity, and efficiency.
Read more

The API security maturity model

  • The API Security Maturity Model is a corollary to the Richardson Maturity Model associated with RESTful API design, describing four levels of REST compliance. It describes cumulative levels of security, complexity, and efficiency.
  • Level 0 uses API keys and basic authentication, which is fundamentally insecure as it assumes whoever has the key is the rightful owner of it. There is basically no separate authorization process.
  • Level 1 uses token-based authentication but still conflates authentication and authorization, or produces quasi-authentication where the token acts as an ID card but is vulnerable to malicious intent as you assume the possession of the token is itself guarantee against mal-intent.
  • Level 2 uses token-based authorization, where authentication tokens allow entry but access and privileges are regulated by a system such as OAuth, with permissions designed to match a token’s lifespan and purpose or be set so that tokens age out of use; however, these systems are designed to be authoritative so you need to ask whether you can trust the system the token comes from, and also consider the reliability of data in transit, as tokens can collect more data and alter it as they pass through the system, so you need to monitor who adds data and what sort.
  • Level 3 uses claims for a centralized trust system, which gathers context and verifies information about the subject rather than simply trusting the caller, API gateway or token issuer; to achieve this, you need an asserting party you trust to verify the context and subject attributes for each claim with signed tokens (using private and public keys).

Full post here, 10 mins read

Improving resiliency and stability of a large-scale monolithic API service

The results of microclustering include the ability to limit downstream failures and bugs to a single vertical, and each cluster can be tuned independently of the others for better capacity planning, monitoring and granular control over deployment.
Read more

Improving resiliency and stability of a large-scale monolithic API service

Lessons from the API layer service used by LinkedIn:

  • They chose a cross-platform design (with all platforms using the same API and same endpoints for the same features) and an all-encompassing design (one API service calls all product verticals), to allow for high code reuse.
  • They reused data-schema definitions and endpoints to make it easier for engineers to collaborate but it led to issues at scale, when extended to deployment architecture. It was addressed by microclustering rather than breaking the monolith into microservices: Endpoints of the services were partitioned without breaking the code, routing traffic for each partition to a dedicated cluster of servers. Data from monitoring systems were used to identify which verticals had enough traffic to justify a partition.
  • For each vertical, the build system was modified to create an additional deployable named after the vertical, with configuration inherited from the shared service and extended. Traffic from the vertical’s endpoints was examined to estimate the number of servers needed in the new cluster.
  • While deploying, capacity testing was carried out - when there was enough traffic to overload at least three servers, servers were slowly taken down to observe latencies and error rates, revealing how many queries-per-second each server could process without incident. This information was used for capacity planning, to fine-tune resource allocation.
  • The results of microclustering include the ability to limit downstream failures and bugs to a single vertical, and each cluster can be tuned independently of the others for better capacity planning, monitoring and granular control over deployment.

Full post here, 5 mins read

To create an evolvable API, stop thinking about URLs

To build an evolvable API, instead of forcing clients to have prior knowledge of URLs, fields and HTTP methods, you should let the client ask the server what is required to complete an operation and indicate the preferred host and path.
Read more

To create an evolvable API, stop thinking about URLs

  • To build an evolvable API, instead of forcing clients to have prior knowledge of URLs, fields and HTTP methods, you should let the client ask the server what is required to complete an operation and indicate the preferred host and path.
  • Critical aspects of evolvable API include:

a) The state of the conversation being stored in the network - not sourced from either client or server.

b) No versioning needed - when you add or remove data from a response, clients should know how to react. If they don’t know how to react to a new feature, they should be able to ignore it and work in the old way.

c) The server owns actions which contain values for URLs, methods, and fields, so that they control where clients go to continue the conversation, with only the entry point hardcoded in the client.

  • With control of URLs in the server, it can run A/B testing and direct clients to different servers running the same instance of the application. The server can also implement a polling functionality to track the status of requests.
  • Model communication on how people actually operate. Think not only about a generic language but developing a shared domain vocabulary.

Full post here, 10 mins read