krakend api gateway pani c: на новом пути конфликтует с существующим подстановочным знаком в существующем префиксе

Question

Я работаю над файлом конфигурации krakend. У меня есть два веб-сервиса, и я хотел бы управлять обеими конечными точками через один API-шлюз (krakend), разделенный префиксом.

Ниже приведена моя конфигурация.

{
  "version": 2,
  "name": "My API Gateway",
  "port": 8080,
  "host": [],
  "endpoints": [
    {
      "endpoint": "/api/entity/{entityID}",
      "output_encoding": "no-op",
      "method": "POST",
      "backend": [
        {
          "url_pattern": "/api/entity/{entityID}",
          "encoding": "no-op",
          "host": [
            "http://987.654.32.1"
          ]
        }
      ]
    },
    {
      "endpoint": "/api/entity/member/assign/{userID}",
      "output_encoding": "no-op",
      "method": "GET",
      "backend": [
        {
          "url_pattern": "/api/entity/member/assign/{userID}",
          "encoding": "no-op",
          "host": [
            "http://123.456.789.0"
          ]
        }
      ]
    }
  ]
}

при запуске krakend используя docker run, я получил эту информацию об ошибке

panic: 'member' in new path '/api/entity/member/assign/:userID' conflicts with existing wildcard ':entityID' in existing prefix '/api/entity/:entityID'

Насколько я понимаю, {entityID} в первой конечной точке конфликтует с /member/ во второй конечной точке, это как который? Может кто-нибудь, пожалуйста, просветите меня, спасибо заранее.

Answer 1

Это известное ограничение для библиотеки Gin , которую KrakenD использует внутренне, вы можете воспроизвести это поведение непосредственно в библиотеке с помощью этого кода go, который будет воспроизводить точно такую ​​же проблему:

package main

import "github.com/gin-gonic/gin"

func main() {
    r := gin.New()
    r.GET("/ping", handler)
    r.GET("/ping/foo", handler)
    r.GET("/ping/:a", handler)
    r.GET("/ping/:a/bar", handler)
}

func handler(c *gin.Context) {
    c.JSON(200, gin.H{
        "message": "pong",
    })
}

См. Код в этой проблеме .

Решение состоит в том, чтобы объявить пути конечных точек, которые не сталкиваются с подмножествами других конечных точек. В вашей конфигурации конечная точка /api/entity/member/assign/{userID} является подмножеством /api/entity/{entityID}.

Обратите внимание, что {placeholders} подобны использованию подстановочных знаков, поэтому ваша первая конечная точка может быть выражена в других системах, таких как /api/entity/*, и, следовательно, /api/entity/member/assign/{userID} является положительным совпадением.

Любое небольшое изменение в вашей конфигурации, когда подстановочный знак не сталкивается, исправит эту ситуацию. Например, следующие две конечные точки будут работать для вас:

/api/entity/find/{entityID}
/api/entity/member/assign/{userID}