Apabila mereka bentuk antara muka API, perhatikan tempat ini!

Artikel ini membawakan anda pengetahuan yang berkaitan tentang API terutamanya perkara yang perlu diberi perhatian semasa mereka bentuk API? Bagi mereka yang berminat untuk mereka bentuk antara muka API yang elegan, mari lihat di bawah saya harap ia akan membantu semua orang.

Kata Pengantar

Dalam kerja sebenar, kami selalunya perlu berurusan dengan platform pihak ketiga dan mungkin menyambung ke antara muka API platform pihak ketiga atau menyediakan antara muka API untuk pihak ketiga panggilan platform.

Maka persoalannya ialah, jika anda mereka bentuk antara muka API yang elegan, bolehkah ia memenuhi keperluan: keselamatan, panggilan berulang, kestabilan, kedudukan yang baik, dsb.?

Hari ini saya ingin bercakap dengan anda tentang beberapa perkara yang anda perlu beri perhatian semasa mereka bentuk antara muka API saya harap ia akan membantu anda.

1. Tandatangan

Untuk mengelakkan data dalam antara muka API daripada diganggu, banyak kali kita perlu melakukan 签名 pada antara muka API.

Peminta antara muka menyambung 请求参数 + 时间戳 + 密钥 ke dalam rentetan, dan kemudian menjana tanda hadapan melalui algoritma cincang seperti md5.

Kemudian tambahkan parameter tanda pada parameter permintaan atau pengepala permintaan dan hantarkannya ke antara muka API.

Perkhidmatan get laluan antara muka API memperoleh nilai tanda, kemudian menggunakan parameter permintaan + cap masa + kunci yang sama untuk menyambungkannya ke dalam rentetan, menggunakan algoritma m5 yang sama untuk menghasilkan tanda lain dan membandingkan dua tanda Sama ada nilainya sama.

Jika dua tanda adalah sama, ia dianggap sebagai permintaan yang sah dan perkhidmatan get laluan antara muka API akan memajukan permintaan itu kepada sistem perniagaan yang sepadan.

Jika kedua-dua tanda tidak sama, perkhidmatan get laluan antara muka API akan terus mengembalikan ralat tandatangan.

Inilah persoalannya: Mengapakah cap masa perlu ditambah pada tandatangan?

Jawapan: Atas sebab keselamatan, untuk mengelakkan permintaan yang sama daripada digunakan berulang kali dan meningkatkan kemungkinan kunci tidak retak, kami mesti menetapkan masa tamat tempoh yang munasabah untuk setiap permintaan, seperti: 15 minit .

Permintaan sedemikian sah dalam masa 15 minit Jika melebihi 15 minit, perkhidmatan get laluan antara muka API akan mengembalikan gesaan pengecualian yang menunjukkan bahawa tempoh sah telah tamat.

Pada masa ini terdapat dua bentuk kunci yang digunakan dalam menjana tandatangan:

Salah satunya ialah kedua-dua pihak bersetuju dengan privateKey nilai tetap.

Lainnya ialah penyedia antara muka API memberikan dua nilai ​​AK/SK, dan kedua-dua pihak bersetuju untuk menggunakan SK sebagai kunci dalam tandatangan. Pemanggil antara muka AK menghantarnya kepada penyedia antara muka API sebagai accessKey dalam pengepala, supaya penyedia antara muka API boleh mendapatkan SK berdasarkan AK dan menjana sgin baharu.

2. Penyulitan

Kadangkala, antara muka API kami secara langsung menghantar data yang sangat penting, seperti: nombor kad bank pengguna, jumlah pemindahan, kad ID pengguna, dll. Jika parameter ini adalah Sangat berbahaya untuk mendedahkan teks secara terus kepada Internet awam.

Daripada ini, kita perlu 加密 melaksanakan data.

Pada masa ini, BASE64 digunakan untuk penyulitan dan penyahsulitan.

Kami boleh menyambung semua data menjadi rentetan besar mengikut peraturan tertentu, dan kemudian menambah 密钥 untuk menggabungkannya bersama.

Kemudian gunakan kelas alat Base64 selepas JDK1.8 untuk pemprosesan kesannya adalah seperti berikut:

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

Untuk keselamatan, Base64 boleh digunakan untuk menyulitkan beberapa kali.

Apabila pemanggil antara muka API melepasi parameter, terdapat hanya satu data parameter dalam badan, iaitu data yang disulitkan selepas base64.

Perkhidmatan get laluan antara muka API, selepas menerima data data, menyahsulitnya mengikut kunci, algoritma penyulitan, masa penyulitan, dsb. yang telah ditetapkan oleh kedua-dua pihak dan menyahsiri data parameter.

3. Senarai putih IP

Untuk mengukuhkan lagi keselamatan antara muka API dan mengelakkan tandatangan atau penyulitan antara muka daripada retak, penyerang boleh meminta antara muka pada pelayannya sendiri .

Permintaan had permintaan ip, tingkatkan ip白名单.

Hanya alamat IP dalam senarai putih boleh berjaya meminta antara muka API, jika tidak, ia tidak akan mengembalikan hak akses secara langsung.

Senarai putih IP juga boleh ditambah pada perkhidmatan get laluan API.

Tetapi ia juga perlu untuk mengelakkan pelayan aplikasi dalaman syarikat daripada dilanggar Dalam kes ini, permintaan antara muka API juga boleh dimulakan dari pelayan dalaman.

Pada masa ini, anda perlu menambah tembok api web, seperti ModSecurity, dsb.

4. Had Semasa

Jika antara muka API anda dipanggil oleh platform pihak ketiga, ini bermakna kekerapan panggilan tidak boleh dikawal.

Apabila platform pihak ketiga memanggil antara muka API anda, jika konkurensi terlalu tinggi, perkhidmatan API anda mungkin tidak tersedia dan antara muka akan ditutup terus.

Oleh itu, antara muka API mesti 限流 dilakukan.

Terdapat tiga kaedah pengehadan semasa:

• Hadkan IP yang diminta: Contohnya, IP yang sama tidak boleh digunakan untuk API接口总的请求次数 lebih daripada 10,000 kali dalam satu minit .

• Hadkan antara muka permintaan: Contohnya, untuk IP yang sama, dalam masa satu minit, bilangan permintaan kepada 指定的API接口 tidak boleh melebihi 2,000 kali.

• Hadkan pengguna yang meminta: Contohnya, untuk AK/SK用户 yang sama, jumlah bilangan permintaan ke antara muka API tidak boleh melebihi 10,000 kali dalam satu minit.

我们在实际工作中，可以通过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. Reka bentuk Idempotent

Kemungkinan besar platform pihak ketiga akan meminta antara muka kami beberapa kali dalam tempoh masa yang sangat singkat, contohnya: dua kali dalam 1 saat. Mungkin terdapat pepijat dalam sistem perniagaan mereka, atau panggilan antara muka gagal dicuba semula, jadi antara muka API kami perlu 幂等设计.

Maksudnya, adalah perlu untuk menyokong platform pihak ketiga untuk meminta antara muka API beberapa kali dengan parameter yang sama dalam tempoh masa yang sangat singkat Pada kali pertama pangkalan data diminta, data baharu akan ditambah, tetapi selepas permintaan kedua, data tidak akan ditambah Data baharu ditambah, tetapi kejayaan juga akan dikembalikan.

Tujuan ini adalah untuk tidak menjana data yang salah.

Dalam kerja harian kami, kami boleh memastikan ketidakupayaan antara muka dengan menambahkan 数据库 pada 唯一索引 atau menyimpan redis dan meminta parameter dalam requestId.

Bagi mereka yang berminat dengan idempotence antara muka, anda boleh membaca artikel saya yang lain "Bagaimana untuk memastikan idempotence antara muka di bawah konkurensi tinggi? ", yang mempunyai pengenalan yang sangat terperinci.

10 Hadkan bilangan rekod

Untuk antara muka kelompok yang diberikan kepada saya, ia mestilah 限制请求的记录条数.

Jika terlalu banyak data diminta, ia boleh menyebabkan API接口超时 dan masalah lain dengan mudah, menjadikan antara muka API tidak stabil.

Biasanya, adalah disyorkan bahawa parameter dalam permintaan menyokong sehingga 500 rekod.

Jika pengguna memasukkan lebih daripada 500 rekod, antara muka akan terus memberikan gesaan.

Adalah disyorkan bahawa parameter ini boleh dikonfigurasikan dan dirundingkan dengan platform pihak ketiga terlebih dahulu untuk mengelakkan masalah yang tidak perlu selepas pergi ke dalam talian.

11. Ujian tekanan

Sebelum pergi dalam talian, kita mesti melakukan 压力测试 antara muka API untuk mengetahui status qps setiap antara muka.

Supaya kami boleh menganggarkan bilangan nod pelayan yang perlu digunakan dengan lebih baik, yang penting untuk kestabilan antara muka API.

Walaupun antara muka API telah dihadkan pada masa lalu, terdapat tanda tanya sama ada antara muka API sebenarnya boleh mencapai ambang had Jika tiada ujian tekanan dilakukan, terdapat risiko yang besar.

Contohnya: Antara muka API anda terhad kepada hanya membenarkan 50 permintaan sesaat, tetapi antara muka API sebenar hanya boleh mengendalikan 30 permintaan, jadi antara muka API anda tidak akan dapat mengendalikannya.

Kami boleh menggunakan jmeter atau apache benc untuk menguji tekanan antara muka API di tempat kerja.

12. Pemprosesan tak segerak

Logik antara muka API umum diproses secara serentak, dan hasilnya dikembalikan serta-merta selepas permintaan selesai.

Tetapi kadangkala, logik perniagaan dalam antara muka API kami adalah sangat kompleks, terutamanya untuk beberapa antara muka kelompok Jika perniagaan diproses secara serentak, ia akan mengambil masa yang sangat lama.

Dalam kes ini, untuk meningkatkan prestasi antara muka API, kami boleh menukarnya kepada 异步处理.

Anda boleh menghantar mq消息 dalam antara muka API, dan kemudian terus mengembalikan kejayaan. Selepas itu, terdapat mq消费者 khas untuk menggunakan mesej secara tidak segerak dan melakukan pemprosesan logik perniagaan.

Platform pihak ketiga boleh mendapatkan antara muka pemprosesan tak segerak secara langsung dalam dua cara.

Cara pertama ialah: kami 回调 menggunakan antara muka platform pihak ketiga untuk memaklumkan mereka tentang hasil pemprosesan antara muka API Ini ialah bilangan antara muka pembayaran yang berfungsi.

Cara kedua ialah: platform pihak ketiga memanggil antara muka API kami yang lain untuk status pertanyaan melalui 轮询 dan menanyakan status sekali-sekala Parameter yang dihantar ialah id dalam API sebelumnya antara muka berkumpul.

13. Penyahpekaan data

Kadangkala apabila platform pihak ketiga menghubungi antara muka API kami, beberapa data yang diperoleh adalah data sensitif, seperti nombor telefon mudah alih pengguna, nombor kad bank, dsb.

Jika maklumat sedemikian disimpan terus pada rangkaian luaran melalui antara muka API, ia sangat tidak selamat dan boleh membawa kepada kebocoran data privasi pengguna dengan mudah.

Ini memerlukan melakukan 数据脱敏 pada beberapa data.

Kami boleh menggantikan sebahagian kandungan dengan 星号 dalam data yang dikembalikan.

Nombor telefon mudah alih yang digunakan sebagai contoh: 182****887.

Dengan cara ini, walaupun data dibocorkan, hanya sebahagian daripadanya akan dibocorkan, dan tidak berguna untuk penjenayah mendapatkan data ini.

14 Dokumen antara muka yang lengkap

Sejujurnya, dokumen antara muka API yang lengkap boleh mengurangkan banyak kos komunikasi dan menyelamatkan pihak lain daripada membuat banyak lencongan apabila kedua-dua pihak melakukan dok antara muka .

Dokumen antara muka perlu mengandungi maklumat berikut:

• Alamat antara muka

• Kaedah permintaan, seperti: pos atau get

• Pengenalan untuk meminta parameter dan medan

• Pengenalan untuk mengembalikan nilai dan medan

• Kembalikan kod dan mesej ralat

• Contoh penyulitan atau tandatangan

• Demo permintaan penuh

• Arahan tambahan, seperti: membuka senarai putih IP.

Adalah yang terbaik untuk menyatukan gaya penamaan antara muka dan nama medan dalam dokumen antara muka, contohnya, gunakan 驼峰标识 untuk menamakannya.

Satukan jenis dan panjang medan, contohnya: medan id menggunakan jenis Panjang dan panjangnya ditentukan sebagai 20. Medan status menggunakan jenis int, dengan panjang tetap 2, dsb.

Medan format masa seragam, contohnya: masa menggunakan Jenis rentetan, formatnya ialah: yyyy-MM-dd HH:mm:ss.

Dokumen antara muka menyatakan AK/SK dan nama domain, dan meminta seseorang untuk memberikannya secara berasingan.

Pembelajaran yang disyorkan: "Tutorial Video PHP"

Atas ialah kandungan terperinci Apabila mereka bentuk antara muka API, perhatikan tempat ini!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!