如何使用 Postman 自动化 API 测试

API 是您作为开发人员构建的几乎每个应用程序的驱动力，充当两个或多个软件组件之间的通信渠道。

但是，这种类型的系统的后果是一个组件的故障可能会对依赖它的其他组件产生重大影响。因此，广泛测试您的 API 以确保应用程序的正确性和可预测性至关重要。

有许多不同的方法可以测试您的 API，您选择的任何方法或方法组合最终将取决于您当前的业务需求、可用资源和实施细节。

在本文中，我们将探讨如何为将在 CI/CD 管道中运行的 API 编写自动化功能和集成测试。

为什么要自动化 API 测试？

编写测试有助于确保您的应用程序在任何给定时间的可预测性和正确性。因此，您应该在代码库更改时运行测试。像这样的重复性任务通常是自动化的良好候选者。

自动化测试让您有信心对应用程序进行更改和添加新功能，因为您始终可以依靠测试来指出您可能引入的错误。

使用 Postman 编写 API 测试

Postman是一个为构建、测试、记录和模拟 API 提供一整套工具的平台。作为开发人员，您很可能在本地开发时使用 Postman 向后端应用程序发出请求，但您可以用它做更多事情。

设置邮递员

要学习本教程，您需要一个 Postman 帐户。如果您还没有，请创建一个免费帐户。然后，导航到您的 Postman 工作区以开始使用。

我们将创建一个名为的新集合Delivery-API Tests，我们将在其中为我们将在本节稍后创建的交付 API 编写一些功能和集成测试。功能测试检查单个 API 端点的行为并确保请求-响应周期符合预期。另一方面，集成测试检查可以由两个或多个端点组成的特定流，以确定用户流中涉及的不同组件是否按预期工作。

此时，您的工作区应在左侧面板中显示该集合：

设置请求

接下来，我们需要创建将保存我们的测试的请求。一个请求将代表一个 API 端点。在Delivery-API Tests集合上，单击右侧出现的菜单按钮。

选择添加请求并命名创建的请求Search Deliveries。再创建三个名为Select Delivery、Confirm Pickup和的请求Complete Delivery。

现在，我们需要为每个请求编写测试。Postman 有一个内置的测试工具，允许您使用 JavaScript 语法编写测试。运行请求后立即执行测试，您可以在测试脚本中访问从请求返回的响应。

在Delivery-API Tests集合中，选择Search Deliveries请求并选择测试选项卡。将以下代码块粘贴到编辑器中：

const responseJson = pm.response.json()

pm.test("response status", function() {
    pm.response.to.have.status(200)
})

pm.test("data contains results", function() {
    pm.expect(responseJson).to.haveOwnProperty("data")
    pm.expect(responseJson.data).to.be.an("array")
    pm.expect(responseJson.data[0]).to.haveOwnProperty("status")
})

pm.collectionVariables.set("SELECTED_DELIVERY_ID", responseJson.data[0].id)

在上面的代码中，我们通过调用获取 JSON 格式的响应pm.response.json()。请注意，这pm是一个在所有请求脚本中都可用的全局对象。然后，我们使用pm.test.

如果您熟悉 JavaScript 中的测试，那么这里的语法应该很简单。Postman 支持Chai 断言库中的语法，因此您可以像在 JavaScript 中那样编写测试。

在测试用例中，我们正在检查正确的状态代码、返回的数据类型以及一些额外的必填字段。这些都是简单的测试，但目标是理解 Postman 中的测试概念。

请注意，在代码块的最后一行，我们设置了一个名为SELECTED_DELIVERY_ID. 集合变量是跨请求共享数据的一种直观方式。

接下来，我们要为其他请求编写测试。将以下代码块粘贴到相应的请求中：

// Select Delivery
const responseJson = pm.response.json()

pm.test("response status", function() {
    pm.response.to.have.status(200)
})

pm.test("data contains result", function() {
    pm.expect(responseJson).to.haveOwnProperty("data")
    pm.expect(responseJson.data).to.be.an("object")
    pm.expect(responseJson.data).to.haveOwnProperty("status")
    pm.expect(responseJson.data.status).to.eql("QUEUED")
})


// Confirm Pickup
const responseJson = pm.response.json()

pm.test("response status", function() {
    pm.response.to.have.status(200)
})

pm.test("data contains result", function() {
    pm.expect(responseJson).to.haveOwnProperty("data")
    pm.expect(responseJson.data).to.be.an("object")
    pm.expect(responseJson.data).to.haveOwnProperty("status")
    pm.expect(responseJson.data.status).to.eql("PICKED_UP")
})


// Complete Delivery
const responseJson = pm.response.json()

pm.test("response status", function() {
    pm.response.to.have.status(200)
})

pm.test("data contains result", function() {
    pm.expect(responseJson).to.haveOwnProperty("data")
    pm.expect(responseJson.data).to.be.an("object")
    pm.expect(responseJson.data).to.haveOwnProperty("status")
    pm.expect(responseJson.data.status).to.eql("COMPLETED")
})

除了字段上的断言外，其他请求的测试用例是相同的status。现在我们已经对我们的请求进行了测试，让我们运行它们。我们需要创建一个处理 API 请求的后端服务器。您可以使用任何语言或框架实现后端服务器，只要它符合 REST 标准，但在本文中，我们将使用Koa构建一个简单的 Node.js 服务器。

构建 API 服务器

在您的终端中，创建一个文件夹并使用 Yarn 或 npm 初始化一个 Node.js 项目：

$ mkdir delivery-api
$ cd delivery-api
$ yarn init -y 

现在，创建一个名为app.js并安装必要的依赖项的文件：

$ touch app.js
$ yarn add koa @koa/router

在您的package.json文件中，添加以下脚本：

//...
  "scripts": {
    "start": "node app.js"
  },
//...

Koa 是一个用于 Node.js 的轻量级 HTTP 中间件框架，类似于 Express。让我们初始化一个 Koa 服务器并定义与我们在 Postman 中设置的请求相对应的路由处理程序。在您的app.js文件中，粘贴以下代码块：

const Koa = require("koa");
const Router = require("@koa/router");
const app = new Koa();
const router = new Router();

app.use(router.routes());

const deliveries = [
   {
      id: "1",
      pickupAddress: "1000 4th Ave, Seattle, WA, 98104",
      pickupPhoneNumber: "+14148928000",
      dropoffAddress: "1201 3rd Ave, Seattle, WA, 98101",
      dropoffPhoneNumber: "+14148928000",
      instructions: "",
      status: "CREATED",
   },
   {
      id: "2",
      pickupAddress: "1000 4th Ave, Seattle, WA, 98104",
      pickupPhoneNumber: "+14148915000",
      dropoffAddress: "1201 3rd Ave, Seattle, WA, 98101",
      dropoffPhoneNumber: "+14148915000",
      instructions: "",
      status: "CREATED",
   },
];

router.get("/deliveries", (ctx) => {
   ctx.body = {
      status: "00",
      message: "successs",
      data: deliveries,
   };
});

router.get("/deliveries/:id/select", (ctx) => {
   const id = ctx.params["id"];
   const delivery = deliveries.find((obj) => obj.id === id);
   if (!delivery) {
      ctx.body = {
         status: "01",
         message: "not found",
         data: null,
      };
   }
   ctx.body = {
      status: "00",
      message: "successs",
      data: { ...delivery, status: "QUEUED" },
   };
});

router.get("/deliveries/:id/confirm-pickup", (ctx) => {
   const id = ctx.params["id"];
   const delivery = deliveries.find((obj) => obj.id === id);
   if (!delivery) {
      ctx.body = {
         status: "01",
         message: "not found",
         data: null,
      };
   }
   ctx.body = {
      status: "00",
      message: "successs",
      data: { ...delivery, status: "PICKED_UP" },
   };
});

router.get("/deliveries/:id/complete", (ctx) => {
   const id = ctx.params["id"];
   const delivery = deliveries.find((obj) => obj.id === id);
   if (!delivery) {
      ctx.body = {
         status: "01",
         message: "not found",
         data: null,
      };
   }
   ctx.body = {
      status: "00",
      message: "successs",
      data: { ...delivery, status: "COMPLETED" },
   };
});

app.listen(8000);

这里发生了很多事情，所以让我们分解一下。首先，我们初始化一个新的 Koa 应用程序和一个新Router对象。使用该router实例，我们定义了四个路由，其路径与我们在 Postman 中创建的请求相匹配。最后，我们通过调用来启动服务器app.listen()。

总之，这个简单的 API 服务器试图模拟送餐应用程序的订单交付过程。现在，通过yarn start在终端中运行来启动服务器。

在 Postman 上运行手动测试

现在，我们已经设置好一切来运行测试。如果您在网络上使用 Postman，您将无法连接到localhost. 但是，有两种方法可以解决此问题。您可以下载Postman 桌面应用程序 或使用ngrok作为隧道将您的localhost端口公开到互联网。

如果您决定使用 ngrok，您需要做的就是安装它并启动一个指向您的服务器的隧道。打开另一个终端实例，然后运行以下命令并复制显示的 URL：

$ ngrok http 8000

URL 应类似于https://3d43-154-130-109-210.ngrok.io. 在 Web 或桌面上导航到 Postman，选择Delivery-API Tests集合，然后打开变量选项卡。

如果您不使用 Postman 桌面，请使用API_BASE_URL键添加变量并将值设置为或 ngrok URL。http://localhost:8000添加新变量时请务必点击Persist All以确保外部服务可以访问它：

现在，我们可以为每个请求使用集合变量。将每个请求的 URL 字段更新为以下值：

• Search Deliveries：{{API_BASE_URL}}/deliveries?page=1&count=20
• Select Delivery：{{API_BASE_URL}}/deliveries/:id/select
• Confirm Pickup：{{API_BASE_URL}}/deliveries/:id/confirm-pickup
• Complete Delivery：{{API_BASE_URL}}/deliveries/:id/complete

我们可以使用两种方法之一手动运行我们的测试。第一种是单独运行请求，允许执行每个请求的测试脚本。或者，我们可以使用集合运行器一次运行集合。我们将在下一节中使用收集运行器，但您可以通过单击“发送”按钮临时手动运行每个请求。

当您运行请求时，您会在底部面板中看到响应，但您也可以通过单击底部面板中的测试结果选项卡来查看测试结果：

这就是在 Postman 中运行测试所需要做的一切。但是，每当您对代码库进行更改时，访问您的 Postman 工作区并运行测试都感觉不直观。这种方法与开发工作流程不一致，所以让我们对其进行改进。

自动化您的 API 测试

在本节中，我们将通过自动化工作流程使测试过程更直观、更省时。优化的开发工作流程涉及进行本地更改并将新功能推送到源代码控制，在那里它们被 CI/CD 管道拾取，触发一些构建或部署任务。

Postman 提供了一个名为 Newman 的命令行工具，可让您从 CLI 运行集合。它还提供与 CI/CD 环境的无缝集成，这意味着我们可以将测试设置为在部署步骤中运行。这极大地简化了测试过程，使我们不必经常在工作区中运行测试。

将 Newman 与 GitHub Actions 集成

我们可以在许多持续集成服务中设置纽曼。在本文中，我们将使用 GitHub Actions。让我们首先为 Newman 定义一个工作流程。在您的delivery-api项目中，运行以下命令：

$ mkdir .github
$ mkdir .github/workflows
$ touch .github/workflows/postman-tests.yml

将以下工作流定义添加到postman-tests.yml文件中：

# postman-tests.yml
name: Newman Run
on:
  push:
    branches:
      - main
  # types: [closed]
jobs:
  newman:
    name: Postman-tests
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Install Node
        uses: actions/setup-node@v3
        with:
          node-version: 14
      - name: Install Newman & Reporter
        run: |
          npm install -g newman
          npm install -g newman-reporter-htmlextra
      # Make directory for test results in workspace
      - name: Make Directory
        run: mkdir -p newman-results
      # Run newman cli
      - name: Run Newman
        env:
          POSTMAN_API_URL: 'https://api.getpostman.com'
          POSTMAN_API_KEY: ${{ secrets.POSTMAN_API_KEY }}
          POSTMAN_COLLECTION_UID: ${{ secrets.POSTMAN_COLLECTION_UID }}
        run: |
          newman run "${{env.POSTMAN_API_URL}}/collections/${{env.POSTMAN_COLLECTION_UID}}?apikey=${{env.POSTMAN_API_KEY}}" \
          -r htmlextra,cli --reporter-htmlextra-export newman-results/htmlreport.html
      # Upload test results to workspace
      - name: Upload Results
        uses: actions/upload-artifact@v3
        with:
          name: Postman_Test_Reports
          path: newman-results

上面的代码是一个简单的工作流，当我们推送到存储库时运行，特别是在默认main分支上。我们通过一系列步骤为 Postman 测试定义一个作业。

首先，我们运行 checkout 操作，然后使用预定义的操作安装actions/setup-node@v3Node.js。接下来，我们安装 Newman 和newman-reporter-htmlextra. Reporter 是 Newman 的一个插件，可以生成 HTML 格式的测试摘要。然后，我们使用一些参数运行 Newman CLI 工具，包括我们集合的 Postman API URL。

请注意，我们已经定义了一些环境变量。和正在从 GitHub Action 机密中提取POSTMAN_API_KEY。POSTMAN_COLLECTION_UID在设置这些秘密之前，我们需要创建一个存储库。最后，在运行 Newman 之后，我们使用预定义的操作actions/upload-artifact@v3将记者生成的 HTML 文件上传到我们以后可以访问的位置。

把这一切放在一起

最后，我们需要将项目推送到 GitHub 并查看工作流运行情况。导航到您的 GitHub 帐户，创建一个名为 的新存储库delivery-api，然后复制远程 URL。接下来，我们将在项目中初始化 Git，添加远程 URL，提交我们的更改，然后推送更改：

$ git init -b main
$ git remote add origin <your-remote-url>
$ git add .
$ git commit "<message>"
$ git push -u origin main

如果您Actions在 GitHub 存储库中打开选项卡，您应该会看到工作流正在运行或已失败。这是因为我们没有添加密钥。

为了解决这个问题，我们需要在 Postman 上生成一个 API 密钥并获取集合 UID。导航到您的 Postman 工作区；在顶部菜单栏中，单击您的个人资料并选择设置。从侧面导航中选择API Keys，然后生成 API 密钥并复制该值。

接下来，GET向 URL 发出请求，并使用与您生成的 API 密钥相等https://api.getpostman.com/collections的密钥和值设置标头。x-api-key您的回复应包含您的收藏列表：

转到您的 GitHub 存储库并在 GitHub 操作机密中添加POSTMAN_API_KEY和。是您POSTMAN_COLLECTION_UID的集合对象中的字段。POSTMAN_COLLECTION_UIDuidDelivery-API Tests

现在，再次转到您的Actions选项卡并尝试重新运行失败的作业。如果一切正常，您应该会在Artifacts面板中看到一个文件，该文件是工作流生成的报告。您可以在浏览器中下载并打开 HTML 文件。

就是这样！我们已经成功地自动化了我们的 API 测试。每次我们进行更改并推送到上游分支时，它都会触发工作流，运行我们的测试。理想情况下，我们希望在部署完成后运行这个工作流，但为了简单起见，我们只定义了 Postman 测试的工作流。

Postman 对 API 测试的限制

Postman 是一个很棒的 AP​​I 测试工具，但它也有其自身的局限性。与软件中的其他所有内容一样，您需要考虑您独特的项目需求来确定适合该工作的工具。首先要考虑的是测试的范围和复杂性。如果您需要编写依赖于某些外部服务的测试，您可能无法轻松实现自动化。

另一个限制是灵活性。因为您在与应用程序逻辑所在的环境不同的环境中编写测试，所以很难共享和重用代码片段。当您想要针对多个不同的请求参数测试 API 端点时，这尤其令人沮丧。Postman 仍然是一个很好的测试工具，作为开发人员，您可以就使用它进行测试做出明智的决定。

结论

在本文中，我们回顾了为什么在您的应用程序中测试 API 很重要。我们探索了使用 Postman 测试我们的 API，包括设置 Newman 和 GitHub Actions。最后，我们回顾了 Postman 的一些测试限制。总体而言，Postman 是构建、测试、记录和模拟 API 的绝佳工具。我希望您喜欢本教程，并祝您编码愉快！

来源：https ://blog.logrocket.com/how-automate-api-tests-postman/

 #api #postman 

What is GEEK

Buddha Community

Top 10 API Security Threats Every API Team Should Know

As more and more data is exposed via APIs either as API-first companies or for the explosion of single page apps/JAMStack, API security can no longer be an afterthought. The hard part about APIs is that it provides direct access to large amounts of data while bypassing browser precautions. Instead of worrying about SQL injection and XSS issues, you should be concerned about the bad actor who was able to paginate through all your customer records and their data.

Typical prevention mechanisms like Captchas and browser fingerprinting won’t work since APIs by design need to handle a very large number of API accesses even by a single customer. So where do you start? The first thing is to put yourself in the shoes of a hacker and then instrument your APIs to detect and block common attacks along with unknown unknowns for zero-day exploits. Some of these are on the OWASP Security API list, but not all.

Insecure pagination and resource limits

Most APIs provide access to resources that are lists of entities such as /users or /widgets. A client such as a browser would typically filter and paginate through this list to limit the number items returned to a client like so:

First Call: GET /items?skip=0&take=10 
Second Call: GET /items?skip=10&take=10

However, if that entity has any PII or other information, then a hacker could scrape that endpoint to get a dump of all entities in your database. This could be most dangerous if those entities accidently exposed PII or other sensitive information, but could also be dangerous in providing competitors or others with adoption and usage stats for your business or provide scammers with a way to get large email lists. See how Venmo data was scraped

A naive protection mechanism would be to check the take count and throw an error if greater than 100 or 1000. The problem with this is two-fold:

1. For data APIs, legitimate customers may need to fetch and sync a large number of records such as via cron jobs. Artificially small pagination limits can force your API to be very chatty decreasing overall throughput. Max limits are to ensure memory and scalability requirements are met (and prevent certain DDoS attacks), not to guarantee security.
2. This offers zero protection to a hacker that writes a simple script that sleeps a random delay between repeated accesses.

skip = 0
while True:    response = requests.post('https://api.acmeinc.com/widgets?take=10&skip=' + skip),                      headers={'Authorization': 'Bearer' + ' ' + sys.argv[1]})    print("Fetched 10 items")    sleep(randint(100,1000))    skip += 10

How to secure against pagination attacks

To secure against pagination attacks, you should track how many items of a single resource are accessed within a certain time period for each user or API key rather than just at the request level. By tracking API resource access at the user level, you can block a user or API key once they hit a threshold such as “touched 1,000,000 items in a one hour period”. This is dependent on your API use case and can even be dependent on their subscription with you. Like a Captcha, this can slow down the speed that a hacker can exploit your API, like a Captcha if they have to create a new user account manually to create a new API key.

Insecure API key generation

Most APIs are protected by some sort of API key or JWT (JSON Web Token). This provides a natural way to track and protect your API as API security tools can detect abnormal API behavior and block access to an API key automatically. However, hackers will want to outsmart these mechanisms by generating and using a large pool of API keys from a large number of users just like a web hacker would use a large pool of IP addresses to circumvent DDoS protection.

How to secure against API key pools

The easiest way to secure against these types of attacks is by requiring a human to sign up for your service and generate API keys. Bot traffic can be prevented with things like Captcha and 2-Factor Authentication. Unless there is a legitimate business case, new users who sign up for your service should not have the ability to generate API keys programmatically. Instead, only trusted customers should have the ability to generate API keys programmatically. Go one step further and ensure any anomaly detection for abnormal behavior is done at the user and account level, not just for each API key.

Accidental key exposure

APIs are used in a way that increases the probability credentials are leaked:

1. APIs are expected to be accessed over indefinite time periods, which increases the probability that a hacker obtains a valid API key that’s not expired. You save that API key in a server environment variable and forget about it. This is a drastic contrast to a user logging into an interactive website where the session expires after a short duration.
2. The consumer of an API has direct access to the credentials such as when debugging via Postman or CURL. It only takes a single developer to accidently copy/pastes the CURL command containing the API key into a public forum like in GitHub Issues or Stack Overflow.
3. API keys are usually bearer tokens without requiring any other identifying information. APIs cannot leverage things like one-time use tokens or 2-factor authentication.

If a key is exposed due to user error, one may think you as the API provider has any blame. However, security is all about reducing surface area and risk. Treat your customer data as if it’s your own and help them by adding guards that prevent accidental key exposure.

How to prevent accidental key exposure

The easiest way to prevent key exposure is by leveraging two tokens rather than one. A refresh token is stored as an environment variable and can only be used to generate short lived access tokens. Unlike the refresh token, these short lived tokens can access the resources, but are time limited such as in hours or days.

The customer will store the refresh token with other API keys. Then your SDK will generate access tokens on SDK init or when the last access token expires. If a CURL command gets pasted into a GitHub issue, then a hacker would need to use it within hours reducing the attack vector (unless it was the actual refresh token which is low probability)

Exposure to DDoS attacks

APIs open up entirely new business models where customers can access your API platform programmatically. However, this can make DDoS protection tricky. Most DDoS protection is designed to absorb and reject a large number of requests from bad actors during DDoS attacks but still need to let the good ones through. This requires fingerprinting the HTTP requests to check against what looks like bot traffic. This is much harder for API products as all traffic looks like bot traffic and is not coming from a browser where things like cookies are present.

Stopping DDoS attacks

The magical part about APIs is almost every access requires an API Key. If a request doesn’t have an API key, you can automatically reject it which is lightweight on your servers (Ensure authentication is short circuited very early before later middleware like request JSON parsing). So then how do you handle authenticated requests? The easiest is to leverage rate limit counters for each API key such as to handle X requests per minute and reject those above the threshold with a 429 HTTP response. There are a variety of algorithms to do this such as leaky bucket and fixed window counters.

Incorrect server security

APIs are no different than web servers when it comes to good server hygiene. Data can be leaked due to misconfigured SSL certificate or allowing non-HTTPS traffic. For modern applications, there is very little reason to accept non-HTTPS requests, but a customer could mistakenly issue a non HTTP request from their application or CURL exposing the API key. APIs do not have the protection of a browser so things like HSTS or redirect to HTTPS offer no protection.

How to ensure proper SSL

Test your SSL implementation over at Qualys SSL Test or similar tool. You should also block all non-HTTP requests which can be done within your load balancer. You should also remove any HTTP headers scrub any error messages that leak implementation details. If your API is used only by your own apps or can only be accessed server-side, then review Authoritative guide to Cross-Origin Resource Sharing for REST APIs

Incorrect caching headers

APIs provide access to dynamic data that’s scoped to each API key. Any caching implementation should have the ability to scope to an API key to prevent cross-pollution. Even if you don’t cache anything in your infrastructure, you could expose your customers to security holes. If a customer with a proxy server was using multiple API keys such as one for development and one for production, then they could see cross-pollinated data.

#api management #api security #api best practices #api providers #security analytics #api management policies #api access tokens #api access #api security risks #api access keys

Public ASX100 APIs: The Essential List

We’ve conducted some initial research into the public APIs of the ASX100 because we regularly have conversations about what others are doing with their APIs and what best practices look like. Being able to point to good local examples and explain what is happening in Australia is a key part of this conversation.

Method

The method used for this initial research was to obtain a list of the ASX100 (as of 18 September 2020). Then work through each company looking at the following:

1. Whether the company had a public API: this was found by googling “[company name] API” and “[company name] API developer” and “[company name] developer portal”. Sometimes the company’s website was navigated or searched.
2. Some data points about the API were noted, such as the URL of the portal/documentation and the method they used to publish the API (portal, documentation, web page).
3. Observations were recorded that piqued the interest of the researchers (you will find these below).
4. Other notes were made to support future research.
5. You will find a summary of the data in the infographic below.

Data

With regards to how the APIs are shared:

• Documentation is where just the Swagger/OpenAPI docs are hosted somewhere. e.g. https://api.linkgroup.com/member/docs/index
• Portal is where an interactive portal has been developed. e.g. https://dev.telstra.com/
• The web page is where the company has a single page that isn’t interactive explaining their Public APIs. e.g. https://www.bendigoadelaide.com.au/banking-products-api.asp

#api #api-development #api-analytics #apis #api-integration #api-testing #api-security #api-gateway

An API-First Approach For Designing Restful APIs | Hacker Noon

I’ve been working with Restful APIs for some time now and one thing that I love to do is to talk about APIs.

So, today I will show you how to build an API using the API-First approach and Design First with OpenAPI Specification.

First thing first, if you don’t know what’s an API-First approach means, it would be nice you stop reading this and check the blog post that I wrote to the Farfetchs blog where I explain everything that you need to know to start an API using API-First.

Preparing the ground

Before you get your hands dirty, let’s prepare the ground and understand the use case that will be developed.

Tools

If you desire to reproduce the examples that will be shown here, you will need some of those items below.

• NodeJS
• OpenAPI Specification
• Text Editor (I’ll use VSCode)
• Command Line

Use Case

To keep easy to understand, let’s use the Todo List App, it is a very common concept beyond the software development community.

#api #rest-api #openai #api-first-development #api-design #apis #restful-apis #restful-api

What Are Good Traits That Make Great API Product Managers

As more companies realize the benefits of an API-first mindset and treating their APIs as products, there is a growing need for good API product management practices to make a company’s API strategy a reality. However, API product management is a relatively new field with little established knowledge on what is API product management and what a PM should be doing to ensure their API platform is successful.

Many of the current practices of API product management have carried over from other products and platforms like web and mobile, but API products have their own unique set of challenges due to the way they are marketed and used by customers. While it would be rare for a consumer mobile app to have detailed developer docs and a developer relations team, you’ll find these items common among API product-focused companies. A second unique challenge is that APIs are very developer-centric and many times API PMs are engineers themselves. Yet, this can cause an API or developer program to lose empathy for what their customers actually want if good processes are not in place. Just because you’re an engineer, don’t assume your customers will want the same features and use cases that you want.

This guide lays out what is API product management and some of the things you should be doing to be a good product manager.

#api #analytics #apis #product management #api best practices #api platform #api adoption #product managers #api product #api metrics

54% of Developers Cite Lack of Documentation as the Top Obstacle to Consuming APIs

Recently, I worked with my team at Postman to field the 2020 State of the API survey and report. We’re insanely grateful to the folks who participated—more than 13,500 developers and other professionals took the survey, helping make this the largest and most comprehensive survey in the industry. (Seriously folks, thank you!) Curious what we learned? Here are a few insights in areas that you might find interesting:

API Reliability

Whether internal, external, or partner, APIs are perceived as reliable—more than half of respondents stated that APIs do not break, stop working, or materially change specification often enough to matter. Respondents choosing the “not often enough to matter” option here came in at 55.8% for internal APIs, 60.4% for external APIs, and 61.2% for partner APIs.

Obstacles to Producing APIs

When asked about the biggest obstacles to producing APIs, lack of time is by far the leading obstacle, with 52.3% of respondents listing it. Lack of knowledge (36.4%) and people (35.1%) were the next highest.

#api #rest-api #apis #api-first-development #api-report #api-documentation #api-reliability #hackernoon-top-story