HettАндрей Панфиловпропущено...
на create контракта в ТЗ нет, поэтому 200 там вполне себе, более того, там никаким PUT и не пахнет, поэтому про 201 не может быть и речи.

А задание и ставится с недоговорками, чтобы человек не пошел и не нагуглил (например там не слова про регулярки, а они есть).
В задании сказано вообще про стандартные коды ошибок http (не понятно только как это с заданием связано), могу предположить что это опечатка, и не "коды ошибок" а "коды ответов" имелось в виду.

Если разработчик работал с rest сервисами, то уже "по привычке" сделает все с более подходящими под случай кодами ответа и даже не задумается. При неверном запросе же будет ответ 404, а не 200, почему тогда при создании 200, а не 201?
Я даже не говорю про restful, где для создания и получения сущности должен быть один эндпоинт.

ну 404 это не при неправильном запросе.. запрос как раз таки правильный.. а при запросе сущности которой нет у сервера )) при этом вебдевелоперы тебя за такой ответ скорее всего из рогатки будут расстреливать пока ты спишь.

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

да и структура не очень. имхо, хелло там лишнее. надо только один явный гет\контактс на весь контроллер и всё. если конечно мы хоть как то хотим держать архитектуру реста.

и? какие проблемы. у нас последняя буква это с, х идет после с. список то сортированный -- всё вин. икса нету.

Андрей ПанфиловandreykaTа какая разница бинарному поиску между искать есть ли строка или искать нет ли строки? это ж одно и то же Вы что там курите вообще? Отсортируйте список {"a", "b", "c", } по "во фразе нет буквы 'x'" и сравните сколько будет каждый раз стоить эта сортировка с обычным проходом по списку и выдачей результата
я изначально сказал поиск либо по сортированному списку либо нет. сортировать перед поиском каждый раз не обязательно. можно например, сразу хранить набор данных сортированными.

TsyklopandreykaTда и структура не очень. имхо, хелло там лишнее. надо только один явный гет\контактс на весь контроллер и всё. если конечно мы хоть как то хотим держать архитектуру реста.


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

Андрей ПанфиловandreykaTя изначально сказал поиск либо по сортированному списку либо нет. сортировать перед поиском каждый раз не обязательно. можно например, сразу хранить набор данных сортированными.
первый запрос: в названии нет 'x'
второй запрос: в названии нет 'a'

в каком месте здесь поможет сортировка?
во всех. ну слушайте. погуглите наконец, в ютубе например, ключевую фразу binary search там в форме мультиков описывается как работает этот элементарный алгоритм.

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

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

1 а
2 аа
3 аааа
4 аааааа
5 аааааааааа
6 ааааааааааааааааааа
7 аааааааааааааааааааааааааа
8 ааааааааааааааааааааааааааааааааб
9 ааб
10 абб
11 аввв
12 авввв
13 бвв
мы ищем строки где есть (или нет) буквы "б"

вы тыкаете в индекс 7 -- как вы думаете, по индексу 6 (шесть) может находиться строка где будет буква "б"?

Андрей ПанфиловandreykaTвы тыкаете в индекс 7 -- как вы думаете, по индексу 6 (шесть) может находиться строка где будет буква "б"?У вас магия данных, добавьте между 'а' и 'б' еще букв и увидите что сортировка здесь никак не помогает, ну или возьмите к примеру проверку на четность вхождений подряд: (aa)+ и скажите как здесь поможет сортировка.
да но тогда порядок поменяется.

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

если заказчик что то хочет увидеть то он явно об этом должен сказать. типа хочу это это и это. не хочу то то и то. а тут же я помню шел в какую то контору там вообще ТЗ было из одной ска строки! одной! "напишите двухуровневый конфигурируемый кэш". книжное издание "вилей" емнип а дальше "мы типа больше не пишем т.к. хотим посмотреть ход вашей мысли".
когда я им написал тз мне ответ был весьма краток - "нам не нравится" что почему зачем где как? козлы. тут хоть оценщик что-то да выдавил из себя.

Чел хочет перебрать миллион строк в памяти. Какие ещё варианты могут быть? Спарк чтоле подключать?