Achten Sie beim Entwerfen von API-Schnittstellen auf diese Stellen!

Dieser Artikel vermittelt Ihnen relevantes Wissen über APIs. Er stellt hauptsächlich vor, worauf beim Entwerfen von APIs geachtet werden sollte. Für diejenigen, die daran interessiert sind, eine elegante API-Schnittstelle zu entwerfen, werfen wir einen Blick darauf. Ich hoffe, dass es für alle hilfreich ist.

Vorwort

Bei der tatsächlichen Arbeit müssen wir uns häufig mit Plattformen von Drittanbietern befassen und stellen möglicherweise eine Verbindung zu API-Schnittstellen von Plattformen von Drittanbietern her oder stellen API-Schnittstellen für Plattformaufrufe von Drittanbietern bereit.

Dann stellt sich die Frage: Wenn Sie eine elegante API-Schnittstelle entwerfen, kann diese die folgenden Anforderungen erfüllen: Sicherheit, wiederholbare Aufrufe, Stabilität, gute Positionierung usw.?

Heute werde ich mit Ihnen über einige Dinge sprechen, auf die Sie beim Entwerfen von API-Schnittstellen achten müssen. Ich hoffe, dass es Ihnen hilfreich sein wird.

1. Signatur

Um zu verhindern, dass die Daten in der API-Schnittstelle manipuliert werden, müssen wir die API-Schnittstelle oft signieren. 签名。

接口请求方将请求参数 + 时间戳 + 密钥拼接成一个字符串，然后通过md5等hash算法，生成一个前面sign。

然后在请求参数或者请求头中，增加sign参数，传递给API接口。

API接口的网关服务，获取到该sign值，然后用相同的请求参数 + 时间戳 + 密钥拼接成一个字符串，用相同的m5算法生成另外一个sign，对比两个sign值是否相等。

如果两个sign相等，则认为是有效请求，API接口的网关服务会将给请求转发给相应的业务系统。

如果两个sign不相等，则API接口的网关服务会直接返回签名错误。

问题来了：签名中为什么要加时间戳？

答：为了安全性考虑，防止同一次请求被反复利用，增加了密钥没破解的可能性，我们必须要对每次请求都设置一个合理的过期时间，比如：15分钟。

这样一次请求，在15分钟之内是有效的，超过15分钟，API接口的网关服务会返回超过有效期的异常提示。

目前生成签名中的密钥有两种形式：

一种是双方约定一个固定值privateKey。

另一种是API接口提供方给出AK/SK两个值，双方约定用SK作为签名中的密钥。AK接口调用方作为header中的accessKey传递给API接口提供方，这样API接口提供方可以根据AK获取到SK，而生成新的sgin。

2. 加密

有些时候，我们的API接口直接传递的非常重要的数据，比如：用户的银行卡号、转账金额、用户身份证等，如果将这些参数，直接明文，暴露到公网上是非常危险的事情。

由此，我们需要对数据进行加密。

目前使用比较多的是用BASE64加解密。

我们可以将所有的数据，安装一定的规律拼接成一个大的字符串，然后在加一个密钥，拼接到一起。

然后使用JDK1.8之后的Base64工具类处理，效果如下：

【加密前的数据】www.baidu.com
【加密后的数据】d3d3LmJhaWR1LmNvbQ==复制代码

为了安全性，使用Base64可以加密多次。

API接口的调用方在传递参数时，body中只有一个参数data，它就是base64之后的加密数据。

API接口的网关服务，在接收到data数据后，根据双方事先预定的密钥、加密算法、加密次数等，进行解密，并且反序列化出参数数据。

3. ip白名单

为了进一步加强API接口的安全性，防止接口的签名或者加密被破解了，攻击者可以在自己的服务器上请求该接口。

需求限制请求ip，增加ip白名单。

只有在白名单中的ip地址，才能成功请求API接口，否则直接返回无访问权限。

ip白名单也可以加在API网关服务上。

但也要防止公司的内部应用服务器被攻破，这种情况也可以从内部服务器上发起API接口的请求。

这时候就需要增加web防火墙了，比如：ModSecurity等。

4. 限流

如果你的API接口被第三方平台调用了，这就意味着着，调用频率是没法控制的。

第三方平台调用你的API接口时，如果并发量一下子太高，可能会导致你的API服务不可用，接口直接挂掉。

由此，必须要对API接口做限流。

限流方法有三种：

• 对请求ip做限流：比如同一个ip，在一分钟内，对API接口总的请求次数，不能超过10000次。

• 对请求接口做限流：比如同一个ip，在一分钟内，对指定的API接口，请求次数不能超过2000次。

• 对请求用户做限流：比如同一个AK/SK用户

  Der Schnittstellenanforderer verkettet Anforderungsparameter + Zeitstempel + Schlüssel zu einer Zeichenfolge und übergibt dann md5Wait for Der Hash-Algorithmus zur Generierung eines Vorzeichens. 🎜🎜Fügen Sie dann den Vorzeichenparameter zum Anforderungsparameter oder Anforderungsheader hinzu und übergeben Sie ihn an die API-Schnittstelle. 🎜🎜Der Gateway-Dienst der API-Schnittstelle ruft den Vorzeichenwert ab, verwendet dann dieselben Anforderungsparameter + Zeitstempel + Schlüssel, um ihn zu einer Zeichenfolge zu verbinden, verwendet denselben m5-Algorithmus, um ein weiteres Vorzeichen zu generieren, und vergleicht die beiden Vorzeichenwerte mit Sehen Sie, ob sie gleich sind. 🎜🎜Wenn die beiden Vorzeichen gleich sind, handelt es sich um eine gültige Anfrage und der Gateway-Dienst der API-Schnittstelle leitet die Anfrage an das entsprechende Geschäftssystem weiter. 🎜🎜Wenn die beiden Vorzeichen nicht gleich sind, gibt der Gateway-Dienst der API-Schnittstelle direkt einen Signaturfehler zurück. 🎜🎜Die Frage ist: Warum sollte der Signatur ein Zeitstempel hinzugefügt werden? 🎜🎜Antwort: Um zu verhindern, dass dieselbe Anfrage wiederholt verwendet wird und um die Wahrscheinlichkeit zu erhöhen, dass der Schlüssel nicht geknackt wird, müssen wir aus Sicherheitsgründen für jede Anfrage eine angemessene Ablaufzeit festlegen, beispielsweise 15 Minuten. 🎜🎜 Eine solche Anfrage ist innerhalb von 15 Minuten gültig. Wenn sie 15 Minuten überschreitet, gibt der Gateway-Dienst der API-Schnittstelle eine Ausnahmemeldung zurück, die darauf hinweist, dass die Gültigkeitsdauer abgelaufen ist. 🎜🎜Derzeit werden bei der Signaturerstellung zwei Arten von Schlüsseln verwendet: 🎜🎜Eine besteht darin, dass sich beide Parteien auf einen privaten Schlüssel mit festem Wert einigen. 🎜🎜Das andere ist, dass der API-Schnittstellenanbieter zwei Werte AK/SK angibt und beide Parteien vereinbaren, SK als Schlüssel in der Signatur zu verwenden. Der AK-Schnittstellenaufrufer übergibt es als accessKey im Header an den API-Schnittstellenanbieter, sodass der API-Schnittstellenanbieter den SK basierend auf dem AK abrufen und einen neuen Sgin generieren kann. 🎜

  2. Verschlüsselung🎜🎜Manchmal überträgt unsere API-Schnittstelle direkt sehr wichtige Daten, wie zum Beispiel: Bankkartennummer des Benutzers, Überweisungsbetrag, Benutzerausweis usw., falls vorhanden Es ist sehr gefährlich, diese Parameter direkt im Klartext dem öffentlichen Netzwerk zugänglich zu machen. 🎜🎜Daher müssen wir die Daten verschlüsseln. 🎜🎜Derzeit wird BASE64 zur Ver- und Entschlüsselung verwendet. 🎜🎜Wir können alle Daten nach bestimmten Regeln zu einer großen Zeichenfolge zusammenfügen und dann einen Schlüssel hinzufügen, um sie zusammenzufügen. 🎜🎜Verwenden Sie dann die Base64-Toolklasse nach JDK1.8 zur Verarbeitung. Der Effekt ist wie folgt: 🎜

  {    
  "code":0,    
  "message":null,    
  "data":[{"id":123,"name":"abc"}]
  },

  🎜Aus Sicherheitsgründen kann Base64 zum mehrfachen Verschlüsseln verwendet werden. 🎜🎜Wenn der Aufrufer der API-Schnittstelle Parameter übergibt, gibt es im Hauptteil nur Parameterdaten, nämlich die verschlüsselten Daten nach Base64. 🎜🎜Der Gateway-Dienst der API-Schnittstelle entschlüsselt die Daten nach dem Empfang gemäß dem von beiden Parteien vorgegebenen Schlüssel, Verschlüsselungsalgorithmus, Verschlüsselungszeiten usw. und deserialisiert die Parameterdaten. 🎜

  3. IP-Whitelist🎜🎜Um die Sicherheit der API-Schnittstelle weiter zu stärken und zu verhindern, dass die Signatur oder Verschlüsselung der Schnittstelle geknackt wird, kann der Angreifer die Schnittstelle anfordern Sein eigener Server. 🎜🎜Bedarfslimit anfordern IP, IP-Whitelist hinzufügen. 🎜🎜Nur IP-Adressen in der Whitelist können die API-Schnittstelle erfolgreich anfordern, andernfalls werden direkt keine Zugriffsrechte zurückgegeben. 🎜🎜IP-Whitelist kann auch zum API-Gateway-Dienst hinzugefügt werden. 🎜🎜Aber wir müssen auch verhindern, dass der interne Anwendungsserver des Unternehmens verletzt wird. In diesem Fall können API-Schnittstellenanforderungen auch vom internen Server initiiert werden. 🎜🎜Zu diesem Zeitpunkt müssen Sie eine Web-Firewall wie ModSecurity usw. hinzufügen. 🎜

  4. Strombegrenzung 🎜🎜Wenn Ihre API-Schnittstelle von einer Drittanbieterplattform aufgerufen wird, bedeutet dies, dass die Häufigkeit der Aufrufe nicht kontrolliert werden kann. 🎜🎜Wenn eine Drittanbieterplattform Ihre API-Schnittstelle aufruft und die Parallelität zu hoch ist, ist Ihr API-Dienst möglicherweise nicht mehr verfügbar und die Schnittstelle hängt sich direkt auf. 🎜🎜Daher ist es notwendig, die API-Schnittstelle aktuell zu begrenzen. 🎜🎜Es gibt drei aktuelle Begrenzungsmethoden: 🎜

  • 🎜Begrenzen Sie die aktuelle der angeforderten IP: Zum Beispiel dieselbe IP, innerhalb einer Minute, API Die Gesamtzahl der Anfragen für die Schnittstelle darf 10.000 nicht überschreiten. 🎜
  • 🎜Beschränken Sie den Fluss von Anforderungsschnittstellen: Beispielsweise darf für dieselbe IP innerhalb einer Minute die Anzahl der Anforderungen an die angegebene API-Schnittstelle 2.000 Mal nicht überschreiten. 🎜
  • 🎜Begrenzen Sie den Fluss anfragender Benutzer: Beispielsweise kann derselbe AK/SK-Benutzer nicht mehr als 10.000 Anfragen an die API-Schnittstelle in einer Minute stellen. 🎜

  我们在实际工作中，可以通过nginx，redis或者gateway实现限流的功能。

  5. 参数校验

  我们需要对API接口做参数校验，比如：校验必填字段是否为空，校验字段类型，校验字段长度，校验枚举值等等。

  这样做可以拦截一些无效的请求。

  比如在新增数据时，字段长度超过了数据字段的最大长度，数据库会直接报错。

  但这种异常的请求，我们完全可以在API接口的前期进行识别，没有必要走到数据库保存数据那一步，浪费系统资源。

  有些金额字段，本来是正数，但如果用户传入了负数，万一接口没做校验，可能会导致一些没必要的损失。

  还有些状态字段，如果不做校验，用户如果传入了系统中不存在的枚举值，就会导致保存的数据异常。

  由此可见，做参数校验是非常有必要的。

  在Java中校验数据使用最多的是hiberate的Validator框架，它里面包含了@Null、@NotEmpty、@Size、@Max、@Min等注解。

  用它们校验数据非常方便。

  当然有些日期字段和枚举字段，可能需要通过自定义注解的方式实现参数校验。

  6. 统一返回值

  我之前调用过别人的API接口，正常返回数据是一种json格式，比如：

  {    
  "code":0,    
  "message":null,    
  "data":[{"id":123,"name":"abc"}]
  },

  签名错误返回的json格式：

  {    
  "code":1001,    
  "message":"签名错误",    
  "data":null
  }

  没有数据权限返回的json格式：

  {
      "rt":10,
      "errorMgt":"没有权限",
      "result":null
      }

  这种是比较坑的做法，返回值中有多种不同格式的返回数据，这样会导致对接方很难理解。

  出现这种情况，可能是API网关定义了一直返回值结构，业务系统定义了另外一种返回值结构。如果是网关异常，则返回网关定义的返回值结构，如果是业务系统异常，则返回业务系统的返回值结构。

  但这样会导致API接口出现不同的异常时，返回不同的返回值结构，非常不利于接口的维护。

  其实这个问题我们可以在设计API网关时解决。

  业务系统在出现异常时，抛出业务异常的RuntimeException，其中有个message字段定义异常信息。

  所有的API接口都必须经过API网关，API网关捕获该业务异常，然后转换成统一的异常结构返回，这样能统一返回值结构。

  7. 统一封装异常

  我们的API接口需要对异常进行统一处理。

  不知道你有没有遇到过这种场景：有时候在API接口中，需要访问数据库，但表不存在，或者sql语句异常，就会直接把sql信息在API接口中直接返回。

  返回值中包含了异常堆栈信息、数据库信息、错误代码和行数等信息。

  如果直接把这些内容暴露给第三方平台，是很危险的事情。

  有些不法分子，利用接口返回值中的这些信息，有可能会进行sql注入或者直接脱库，而对我们系统造成一定的损失。

  因此非常有必要对API接口中的异常做统一处理，把异常转换成这样：

  {    
  "code":500,    
  "message":"服务器内部错误",    
  "data":null
  }

  返回码code是500，返回信息message是服务器内部异常。

  这样第三方平台就知道是API接口出现了内部问题，但不知道具体原因，他们可以找我们排查问题。

  我们可以在内部的日志文件中，把堆栈信息、数据库信息、错误代码行数等信息，打印出来。

  我们可以在gateway中对异常进行拦截，做统一封装，然后给第三方平台的是处理后没有敏感信息的错误信息。

  8. 请求日志

  在第三方平台请求你的API接口时，接口的请求日志非常重要，通过它可以快速的分析和定位问题。

  我们需要把API接口的请求url、请求参数、请求头、请求方式、响应数据和响应时间等，记录到日志文件中。

  最好有traceId，可以通过它串联整个请求的日志，过滤多余的日志。

  当然有些时候，请求日志不光是你们公司开发人员需要查看，第三方平台的用户也需要能查看接口的请求日志。

  这时就需要把日志落地到数据库，比如：mongodb或者elastic search，然后做一个UI页面，给第三方平台的用户开通查看权限。这样他们就能在外网查看请求日志了，他们自己也能定位一部分问题。

  9. Idempotentes Design

  Die Drittanbieterplattform fordert unsere Schnittstelle höchstwahrscheinlich mehrmals in sehr kurzer Zeit an, zum Beispiel: zweimal in 1 Sekunde. Es ist möglich, dass in ihrem Geschäftssystem ein Fehler vorliegt oder sie es erneut versuchen, nachdem ein Schnittstellenaufruf fehlgeschlagen ist. Daher muss unsere API-Schnittstelle idempotent sein. 幂等设计。

  也就是说要支持在极短的时间内，第三方平台用相同的参数请求API接口多次，第一次请求数据库会新增数据，但第二次请求以后就不会新增数据，但也会返回成功。

  这样做的目的是不会产生错误数据。

  我们在日常工作中，可以通过在数据库中增加唯一索引，或者在redis保存requestId和请求参来保证接口幂等性。

  对接口幂等性感兴趣的小伙伴，可以看看我的另一篇文章《高并发下如何保证接口的幂等性？》，里面有非常详细的介绍。

  10. 限制记录条数

  对于对我提供的批量接口，一定要限制请求的记录条数。

  如果请求的数据太多，很容易造成API接口超时等问题，让API接口变得不稳定。

  通常情况下，建议一次请求中的参数，最多支持传入500条记录。

  如果用户传入多余500条记录，则接口直接给出提示。

  建议这个参数做成可配置的，并且要事先跟第三方平台协商好，避免上线后产生不必要的问题。

  11. 压测

  上线前我们务必要对API接口做一下压力测试，知道各个接口的qps情况。

  以便于我们能够更好的预估，需要部署多少服务器节点，对于API接口的稳定性至关重要。

  之前虽说对API接口做了限流，但是实际上API接口是否能够达到限制的阀值，这是一个问号，如果不做压力测试，是有很大风险的。

  比如：你API接口限流1秒只允许50次请求，但实际API接口只能处理30次请求，这样你的API接口也会处理不过来。

  我们在工作中可以用jmeter或者apache benc对API接口做压力测试。

  12. 异步处理

  一般的API接口的逻辑都是同步处理的，请求完之后立刻返回结果。

  但有时候，我们的API接口里面的业务逻辑非常复杂，特别是有些批量接口，如果同步处理业务，耗时会非常长。

  这种情况下，为了提升API接口的性能，我们可以改成异步处理。

  在API接口中可以发送一条mq消息，然后直接返回成功。之后，有个专门的mq消费者去异步消费该消息，做业务逻辑处理。

  直接异步处理的接口，第三方平台有两种方式获取到。

  第一种方式是：我们回调第三方平台的接口，告知他们API接口的处理结果，很多支付接口就是这么玩的。

  第二种方式是：第三方平台通过轮询调用我们另外一个查询状态的API接口，每隔一段时间查询一次状态，传入的参数是之前的那个API接口中的id集合。

  13. 数据脱敏

  有时候第三方平台调用我们API接口时，获取的数据中有一部分是敏感数据，比如：用户手机号、银行卡号等等。

  这样信息如果通过API接口直接保留到外网，是非常不安全的，很容易造成用户隐私数据泄露的问题。

  这就需要对部分数据做数据脱敏了。

  我们可以在返回的数据中，部分内容用星号代替。

  已用户手机号为例：182****887

  Das heißt, es ist notwendig, die Plattform eines Drittanbieters zu unterstützen, um die API-Schnittstelle in sehr kurzer Zeit mehrmals mit denselben Parametern anzufordern. Beim ersten Anfordern der Datenbank werden neue Daten hinzugefügt. aber nach der zweiten Anfrage werden keine neuen Daten hinzugefügt, es wird aber auch Erfolg zurückgegeben.
  Der Zweck besteht nicht darin, fehlerhafte Daten zu generieren.
  In unserer täglichen Arbeit können wir unique index in database hinzufügen oder requestId in redis speichern und anfordern Parameter zur Sicherstellung der Schnittstellen-Idempotenz.
  Freunde, die sich für Schnittstellen-Idempotenz interessieren, können meinen anderen Artikel „So stellen Sie die Idempotenz sicher von Schnittstellen unter hoher Parallelität? “, das eine sehr detaillierte Einführung enthält.

  10. Begrenzen Sie die Anzahl der Datensätze

  Für die mir zur Verfügung gestellte Batch-Schnittstelle müssen Sie unbedingt die Anzahl der angeforderten Datensätze begrenzen.

  • Wenn zu viele Daten angefordert werden, kann es leicht zu API-Schnittstellen-Timeout und anderen Problemen kommen, wodurch die API-Schnittstelle instabil wird.

  Normalerweise wird empfohlen, dass die Parameter in einer Anfrage bis zu 500 Datensätze unterstützen.

  • Wenn der Benutzer mehr als 500 Datensätze eingibt, gibt die Schnittstelle direkt eine Eingabeaufforderung aus.

  Es wird empfohlen, diesen Parameter vorab konfigurierbar zu machen und mit der Drittplattform auszuhandeln, um unnötige Probleme nach dem Online-Gehen zu vermeiden.

  • 11. Stresstest

    Bevor wir online gehen, müssen wir einen Stresstest auf der API-Schnittstelle durchführen, um den qpszu kennen > jeder Schnittstelle >Situation.
  • Damit wir besser abschätzen können, wie viele Serverknoten bereitgestellt werden müssen, was für die Stabilität der API-Schnittstelle von entscheidender Bedeutung ist.
    Obwohl die API-Schnittstelle bisher im aktuellen Fluss begrenzt war, ist es tatsächlich ein Fragezeichen, ob die API-Schnittstelle den Grenzwert erreichen kann. Wenn kein Stresstest durchgeführt wird, besteht ein großes Risiko.
  • Zum Beispiel: Ihre API-Schnittstelle begrenzt den Fluss auf nur 50 Anfragen pro Sekunde, aber die eigentliche API-Schnittstelle kann nur 30 Anfragen verarbeiten, sodass Ihre API-Schnittstelle damit nicht umgehen kann.
    Wir können jmeter oder apache benc verwenden, um Stresstests an der API-Schnittstelle bei der Arbeit durchzuführen.

  12. Asynchrone Verarbeitung

  • Die allgemeine API-Schnittstellenlogik wird synchron verarbeitet und das Ergebnis wird sofort nach Abschluss der Anforderung zurückgegeben.

  Aber manchmal ist die Geschäftslogik in unseren API-Schnittstellen sehr komplex, insbesondere bei einigen Batch-Schnittstellen. Wenn das Geschäft synchron verarbeitet wird, dauert es sehr lange.

  • Um die Leistung der API-Schnittstelle zu verbessern, können wir in diesem Fall sie in asynchrone Verarbeitung ändern.

    🎜In der API-Schnittstelle können Sie eine mq-Nachricht senden und dann direkt Erfolg zurückgeben. Danach gibt es einen dedizierten mq-Konsumenten, der die Nachricht asynchron konsumiert und die Geschäftslogikverarbeitung durchführt. 🎜🎜Die Plattform eines Drittanbieters kann die direkte asynchrone Verarbeitungsschnittstelle auf zwei Arten erhalten. 🎜🎜Der erste Weg ist: Wir rufen die Schnittstelle der Drittplattform zurück, um sie über die Verarbeitungsergebnisse der API-Schnittstelle zu informieren. So funktionieren viele Zahlungsschnittstellen. 🎜🎜Der zweite Weg ist: Die Drittanbieterplattform ruft unsere andere API-Schnittstelle auf, um den Status über Polling abzufragen, und fragt von Zeit zu Zeit den Status ab. Die übergebenen Parameter stammen von der vorherigen API-Schnittstelle . ID-Sammlung. 🎜

    13. Datendesensibilisierung🎜🎜Wenn eine Drittanbieterplattform unsere API-Schnittstelle aufruft, handelt es sich bei einem Teil der erhaltenen Daten manchmal um sensible Daten, wie z. B. die Mobiltelefonnummer des Benutzers oder die Bankkartennummer usw. warten. 🎜🎜Wenn solche Informationen über die API-Schnittstelle direkt im externen Netzwerk gespeichert werden, sind sie sehr unsicher und können leicht zum Verlust von Datenschutzdaten der Benutzer führen. 🎜🎜Dies erfordert für einige Daten eine Datendesensibilisierung. 🎜🎜Wir können einen Teil des Inhalts durch Sternchen in den zurückgegebenen Daten ersetzen. 🎜🎜Nehmen Sie als Beispiel die Mobiltelefonnummer des Benutzers: 182****887. 🎜🎜Auf diese Weise wird, selbst wenn die Daten durchgesickert sind, nur ein Teil davon durchgesickert, und es ist für Kriminelle nutzlos, an diese Daten zu gelangen. 🎜🎜14. Vollständiges Schnittstellendokument🎜🎜Um ehrlich zu sein, kann ein vollständiges API-Schnittstellendokument viele Kommunikationskosten reduzieren und der anderen Partei viele Umwege ersparen, wenn die beiden Parteien Schnittstellen-Docking durchführen. 🎜🎜Die folgenden Informationen müssen im Schnittstellendokument enthalten sein: 🎜🎜🎜🎜Schnittstellenadresse 🎜🎜🎜🎜Anforderungsmethode, z. B.: Rückgabecode und Fehlermeldung posten oder abrufen🎜🎜🎜🎜Beispiel für Verschlüsselung oder Signatur🎜🎜🎜🎜 Vollständige Demo anfordern🎜

  • Zusätzliche Anweisungen, wie zum Beispiel: Öffnen einer IP-Whitelist.

  Am besten vereinheitlichen Sie den Benennungsstil von Schnittstellen- und Feldnamen im Schnittstellendokument, verwenden Sie beispielsweise 驼峰标识, um sie zu benennen.

  Vereinheitlichen Sie den Typ und die Länge der Felder, zum Beispiel: Das ID-Feld verwendet den Typ Long und die Länge wird mit 20 angegeben. Das Statusfeld verwendet den Typ int mit einer festen Länge von 2 usw.

  Einheitliche Zeitformatfelder, zum Beispiel: Zeit verwendet den String-Typ, das Format ist: jjjj-MM-tt HH:mm:ss.

  Geben Sie AK/SK und den Domänennamen im Schnittstellendokument an, bitten Sie jemanden, diese separat anzugeben usw.

  Empfohlenes Lernen: „PHP-Video-Tutorial“
  

Das obige ist der detaillierte Inhalt vonAchten Sie beim Entwerfen von API-Schnittstellen auf diese Stellen!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!