диспетчер wso2api 4.0 с ошибкой Post-запроса: Не найден

#rest #.net-core #wso2 #wso2-am

Вопрос:

Я хочу защитить api .net core с помощью диспетчера api wso2 ,для этого я включил swagger в api и смог получить ответ после . Я создал Api с определением чванства

 http://localhost:5000/swagger/v1/swagger.json
 

и с учетом конечной точки http://localhost:5000/api/BigData который получит ответ в пользовательском интерфейсе swagger

теперь я пытаюсь протестировать api, работающий с токеном, для этой ошибки wso2api, отображающей ошибку

запрос локона от wso2-am

 curl  reuqest  semding  from  wso2-am  ```curl -X 'POST' 
  'http://localhost:8280/api/v1/api/BigData' 
  -H 'accept: application/json' 
  -H 'Content-Type: application/json' 
  -H 'Internal-Key: eyJraWQiOiJnYXRld2F5X2NlcnRpZmljYXRlX2FsaWFzIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJhZG1pbkBjYXJib24uc3VwZXIiLCJpc3MiOiJodHRwczpcL1wvbG9jYWxob3N0Ojk0NDNcL29hdXRoMlwvdG9rZW4iLCJrZXl0eXBlIjoiUFJPRFVDVElPTiIsInN1YnNjcmliZWRBUElzIjpbeyJzdWJzY3JpYmVyVGVuYW50RG9tYWluIjpudWxsLCJuYW1lIjoiQmlnRGF0YUFQSSIsImNvbnRleHQiOiJcL2FwaVwvdjEiLCJwdWJsaXNoZXIiOiJhZG1pbiIsInZlcnNpb24iOiJ2MSIsInN1YnNjcmlwdGlvblRpZXIiOm51bGx9XSwiZXhwIjoxNjI0OTIyMzg3LCJ0b2tlbl90eXBlIjoiSW50ZXJuYWxLZXkiLCJpYXQiOjE2MjQ4NjIzODcsImp0aSI6ImZiYjQ2OGQ0LWUyOTItNGEyZC1hZmEzLTdhNzFlODUxNTlhNCJ9.Xkz9jigCPs3I65kI40rigE6L8mA-w4kks3n7Cabahg1dMVEo8AVs64PXuKBshucuT_vk5ms-7wFiIiI0pdXrL1ymOlEacBtW2r1F-WvV7o9SVw6lpF4EQNsIFi96Exe5Gg0k2wSaG1iErJ2P8boOQGI66fudGfjC-Gt1RJxfE-ZwQ_aS7fNur4G7HFAbBOdSq3yNDWjsMiv9k4IBlQ-IkJj88zSM6eXnHbtiAJKB84bAkFX7PDxXzjdItGkTKBx2oW11SO27xvqlrlJCHh6dcvEKb1_XZIjyrrvQjTGTX0cTgUlL0HQFOL9RwavrDwXh_fsP51zhGbbLozuUbhUKWg' 
  -d '{
  "messageID": "string",
  "tenantName": "string",
  "tenantID": "string",
  "entityID": "string",
  "entityType": "string",
  "dataType": "string",
  "messageKind": "string",
  "routing": "string",
  "payload": "string",
  "type": "string",
  "clientID": "string",
  "userID": "string",
  "isAdmin": true,
  "fabric": "string",
  "capabilityId": "string",
  "sourceSystem": "string",
  "applicationName": "string"
}'```
 

введите описание изображения здесь
когда я снова проверяю конечную точку, ее метод отображения не разрешен
введите описание изображения здесь

введите описание изображения здесь

Комментарии:

1. Можете ли вы попробовать вызвать API с помощью команды cURL и поделиться результатами? Недопустимый 405 метод создается из-за вашей попытки вызвать ресурс GET из браузера (если вы выполняете URL-адрес из браузера, это будет GET и POST). Кроме того, вы можете указать конечную точку производства, которая была настроена в диспетчере API? Если вы указали полный URL-адрес фактической конечной точки в качестве рабочей конечной точки, то API нуждается в рефакторинге

2. вот запрос на завиток, который я отправляю с клиентом swagger post curl -X 'POST' 'http://localhost:5000/api/BigData' -H 'accept: application/json' -H 'Content-Type: application/json' -d '{ "tenantName": "string", "tenantID": "string", "entityID": "string", "entityType": "string", "dataType": "string", "messageKind": "string", "routing": "string", "payload": "string", "type": "string", "clientID": "string", "userID": "string", "isAdmin": true, "fabric": "string", "capabilityId": "string", "sourceSystem": "string", "applicationName": "string"}'

3. URL конечной точки api, который я установил http://localhost:5000/api/BigData как для безопасной среды, так и для производства

4. я отредактировал сообщение для экранов ответов

5. Спасибо вам за обновленную информацию. Я считаю, что вы создали ресурс API с POST помощью as /api/BigData в диспетчере API. Если да, обновите Production Sandbox конечную точку и как http://localhost:5000 (без указания полного URL-адреса, поскольку диспетчер API добавит Ресурс в конце указанной конечной точки). Сохраните API и опробуйте сценарий

Ответ №1:

Как и в случае с общей информацией, я считаю, что вы настроили ресурс API как /api/BigData . Если это так, обновите Production Sandbox конечные точки и как http://localhost:5000 , а не с полным URL-адресом фактической конечной точки, чтобы устранить 404 ошибки.

Менеджер API использует и добавляет ресурсы API, определенные в конце конечных точек производства/песочницы. Поэтому, когда вы настраиваете API и предоставляете его, вы должны быть уверены в выборе правильных конечных точек.

Например:

Если у вас есть реальный серверный сервер со следующей конечной https://backendserver/api/v1/get точкой, а https://backendserver/api/v1/post затем вам необходимо настроить API в диспетчере API следующим образом

  • Создайте API с помощью следующих двух ресурсов
    • /get
    • /post
  • Настройте конечные точки рабочей среды / безопасной среды следующим образом https://backendserver/api/v1

Затем, если вы вызовете API с помощью конечной точки API Manager ( https://apimanager:8243/your-api/v1/get ), /get ресурс будет добавлен к настроенной конечной точке, и запрос будет отправлен как https://backendserver/api/v1/get .

Надеюсь, это объяснит и даст вам краткое представление о сопоставлениях URL-адресов в диспетчере API.