@Kromster - Есть другие системы, где удобнее иерархия - примеры - в студию! наверняка это будут очень упрощённые системы.

@Kromster - я с самого начала говорю о разных системах - о каких таких разных? ))) в мире есть только одна полезная иерархическая система - это стандартный GUI - рисование вложенных окон/контролов на прямоугольном экране. все остальные реальные системы, с которыми приходится работать, не имеют однозначной иерархии. вы только сейчас узнали, что ООП - это игрушка, не применимая в реальной жизни?

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

В первом случае API демонстрирует, что user это самостоятельная сущность со своими заказами, а во втором случае, что есть список заказов из которого можно отфильтровать например по userId - не вижу разницы. если вы её "видите", то замените слово "user" на слово "дата" в вашем предложении - ваша фраза останется настолько же верна. ок, я понял, что объяснить простыми словами вы не можете. видимо, обсуждаемый предмет является объектом понтов/веры, а не инструментом для удобства/профита. говоря языком разработчиков, это свистелка-перделка.

@Kromster - вам запись /api/user/{id}/orders кажется менее "сложной" чем /api/orders?userid={id}? в чём профит-то? кстати, а как независимые сборщики статистики (кибана и т.п.) смогут догадаться, как по URL определить эндпоинт, чтобы правильно собрать статистику по эндпоинтам? раньше всё было просто: до знака вопроса - эндпоинт, после - его параметры

@Kromster - то есть, этот синтаксис сделали, чтобы выделить обязательные параметры запроса? а для кого это нужно? 1. серверу? парсеру на сервере всё равно какой синтаксис парсить. 2. разработчику скрипта, отправляющего запрос? у него мануал с описанием всех операций и всех параметров. 3. промежуточному кэширующему серверу? им тоже пофиг, они всю строку запоминают. 4. админу, читающему логи сервера? типа, чтобы главный параметр запроса стоял на "первом" месте? короче, я теряюсь в догадках - в чём профит и для кого?

@Kromster - вы описали разницу в их синтаксисе, а не семантике. или вы хотели сказать, что /api/resource/parametervalue существует на сервере в виде отдельного статического файла для каждого значения parametervalue? вопрос "зачем оно надо" так и остался не раскрыт.

в чём разница их ролей?

Более интересен вопрос: зачем ввели два разных синтаксиса для одного и того же?

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

в момент отрыва от самолёта нужно присвоить объекту скорость, равную скорости самолёта

Спасибо за пояснение. А к автору ответа - вопрос "А зачем так сильно бежать впереди паровоза?" ))) Мой FF считает, что он обновлён до самой последней версии.

В FF не работает вообще (115.10.0esr)

передать содержимое файла в multipart/form-data

Учитывая, что CNT - целое число от 1 до 100, можно сделать поиск пошагово-оптимального решения динамическим программированием. То есть, на каждом шаге мы строим следующую локально-оптимальную группу (из ещё не вошедших в группы строк) с наиближайшей к 100 суммой, но общее кол-во групп при этом может не быть оптимальным.

а сколько получится групп? тоже до 50?

сколько ожидается чисел на входе? а то на 9 числах ваш алгоритм может успевать за разумное время, а на 99 числах зависнет очень надолго

А что такое canseled? Это can selled или cancelled?