Пост про POST

Новость короткой строкой: Мы научили автоматические сценарии отправлять POST-запросы.

Я понимаю, что это порадует только очень маленькое количество наших пользователей, которые знают, что такое POST-запросы и для чего они нужны. Для них, скорее всего, будет достаточно картинки:

Сценарий, отправляющий POST-запрос из ПланФикса в Telegram

Ну или такой:

Сценарий отправки POST-запроса из ПланФикса в SlackЕсли вам эта новость ни о чем не говорит, это нормально: большая часть взрослых образованных людей понятия не имеет о POST — да оно им, по большому счету, и не нужно. Единственное исключение — если у вас есть необходимость связать ПланФикс с другой своей корпоративной системой управления, возможно имеет смысл дать ссылку на этот пост своим айтишникам.

Дмитрий Гончаренко Команда ПланФикса

 

Извините, что сегодня такой малоинформативный пост — следующий будет интересней 🙂

23 Comments

  1. Дмитрий Гончаренко, а поля Постановщика/Исполнителя для POST можно будет развернуть как для Контрагента задачи? Чтобы, например, отправлять СМС контакту на номер мобильного телефона по какому-то событию…

    1. Дмитрий Гончаренко

      Обсудим это. Теоретически, это возможно, обычно возникает только одна проблема с такими полями: так как в них может содержаться несколько значений, непонятно, по какому из них отдавать дополнительные данные. А если отдавать по всем (исполнителям, к примеру), то непонятно, как адресоваться к ним.

  2. Потрясающе!
    Теперь просто дух захватывает от возможностей интеграции.
    О таком можно было только фантазировать 🙂
    Реальность — она лучше фантазий.

    А можно как-нибудь использовать возвращаемые результаты?
    К примеру возвращается
    {«result»:{«person_id»:2500767342}}
    или
    {
    «error»: «List \»New_listtt\» (id: 7068222) already exists»,
    «code»: «invalid_arg»,
    «result»: «»,
    «existing_list_id»: 7068222
    }

    На этапе отладки это сильно может помочь…
    Да и потом — такие данные могут пригодиться

        1. Дмитрий Гончаренко

          Такой подход мне кажется не очень удобным тем, что сложно будет собрать в одном месте запрос и ответ на него и управлять этим в одном интерфейсе. А настраивать в разных сложно, легко запутаться что, зачем и почему происходит.

      1. Выполняем Post-запрос с целью создания какого-то элемента в стороннем сервисе. Получаем web-ссылку на созданный элемент, или какой-то id. Заполняем кастомное поле задачи полученным значением.

        Может так?

        1. Дмитрий Гончаренко

          Ну вот мне тоже пришел в голову такой вариант + вариант создавать действие с текстом ответа. Оба варианта позволяют вызвать новые сценарии (на изменение задачи и на добавление нового действия), которые будут обрабатывать ответ и в зависимости от него что-то делать дальше.

          1. думаю, что для начала стоит просто создавать новое действие с текстом ответа.
            А где-нить в настройке действия «создавать post-запрос» сделать флажок «дополнительно создать действие с текстом ответа».

            И на текущем этапе этого будет вполне достаточно.

            А все эти правила, кастомные поля… наверное тоже нужно, но с ними слишком уж сложно получается.
            Если уж это реально надо, то тогда ведь можно ваше API использовать.

    1. Дмитрий Гончаренко

      Ответы добавляются действием, а с текстом действия можно работать (если я, конечно. правильно понял о чем речь).

      А вообще, ветка дальнейшего развития по запросам такая:
      — Делаем механизм универсального разбора внешних данных (данные раскладываются в переменные, которые затем могут использоваться в сценариях). Это происходит прямо сейчас.
      — Распространяем действие этого механизма в том числе и на POST-запросы (а еще на правила для почты и интеграции).
      — Делаем механизм принятия GET-запросов — то есть, возможность сгенерировать ссылку, по которой может обратиться внешний сервис и прислать какие-то данные. Для таких запросов сразу будет подключен механизм универсального разбора, о котором я пишу выше.

      1. А есть ли планы по механизму _отправки_ GET-запросов? Чтобы сценарий мог тут же получить в ответ и обработать внешние данные.

        (да, я понимаю, что серверная реализация такого механизма значительно сложнее, чем реализация POST-запросов, ответ на которые сценарию ждать вообще не надо)

Добавить комментарий