Skip to content

Latest commit

 

History

History
53 lines (25 loc) · 4.31 KB

README.md

File metadata and controls

53 lines (25 loc) · 4.31 KB
Raw

Реализовать брокер очередей в виде веб сервиса. Сервис должен обрабатывать 2 метода:

  1. PUT /queue?v=....

    положить сообщение в очередь с именем queue (имя очереди может быть любое), пример:

    curl -XPUT http://127.0.0.1/color?v=red

    curl -XPUT http://127.0.0.1/color?v=green

    curl -XPUT http://127.0.0.1/name?v=alex

    curl -XPUT http://127.0.0.1/name?v=anna

    в ответ {пустое тело + статус 200 (ok)}

    в случае отсутствия параметра v - пустое тело + статус 400 (bad request)

  2. GET /queue

    забрать (по принципу FIFO) из очереди с названием queue сообщение и вернуть в теле http запроса, пример (результат, который должен быть при выполненных put’ах выше):

    curl http://127.0.0.1/color => red

    curl http://127.0.0.1/color => green

    curl http://127.0.0.1/color => {пустое тело + статус 404 (not found)} curl http://127.0.0.1/color => {пустое тело + статус 404 (not found)} curl http://127.0.0.1/name => alex

    curl http://127.0.0.1/name => anna

    curl http://127.0.0.1/name => {пустое тело + статус 404 (not found)}

    при GET-запросах сделать возможность задавать аргумент timeout

    curl http://127.0.0.1/color?timeout=N

    если в очереди нет готового сообщения получатель должен ждать либо до момента прихода сообщения либо до истечения таймаута (N - кол-во секунд). В случае, если сообщение так и не появилось - возвращать код 404.

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

    Порт, на котором будет слушать сервис, должен задаваться в аргументах командной строки.

Запрещается пользоваться какими либо сторонними пакетами кроме стандартных библиотек. (задача в написани кода, а не в использовании чужого)

Желательно (но не обязательно) весь код расположить в одном go-файле (предполагается, что решение будет не больше 200 строк кода) для удобства проверки, никаких дополнительных файлов readme и т.п. не требуется, создание классической структуры каталогов (cmd/internal/...) не требуется.

Лаконичность кода будет восприниматься крайне положительно, не нужна "гибкость" больше, чем требуется для решения именно этой задачи, не нужны логи процесса работы программы (только обработка ошибок), никакого дебага и т.д... чем меньше кода - тем лучше!

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