База штрихкодов: пожелания, предложения, замечания : База штрихкодов

Да, благодарю, я быстро отказался от идеи не потому, что отмахнулся, просто вопрос уже осмысливался и, кстати, на тему того, что не используются другие типы... Я вот сливаю файлики, которые мне из реальных магазинов отдают - попадаются очень даже странные вещи. Но они есть :) Сильно каши не просят, не мешают, вдруг кому-то придет в голову интересная идея использования общего движка, а ограничений натыкано... Опять же, у некоторых сканеры странно настроены... Пусть будет...

А можно пару примеров увидеть таких станных вещей?
Дело конечно хозяйское, но если это действительно мусор (случайно , или наоборот специально подсунутый в базу), то на мой взгляд это не есть хорошо.
Вот например кто-нибудь захочет навредить и нашпигует базу всякими ААААА11111 и т.д..., для прикола.
Сами же говорите, что ресурсов не хватает для хранения даных, а защиты от явного мусора не предусмотрено.

1. Добавил (описал в доке)
2. Приходит ответ 402 (общее правило, если код не описан, можно его посмотреть в справочнике HTTP-кодов, я возвращаю штатные)
3. Да, опечатался в доке, поправил, спасибо.

Вот, пример аномалий





Нашпиговать можно, увы, только журнал у меня тоже есть. Либо по журналу откачу, либо достану из бекапа, идеальной защиты тут нет.
Ресурсов не хватает не для хранения данных, а для того, чтобы их раздавать в безграничном количестве. Все перекодировки в JSON и поиск по базе требуют ресурсов проца. А он, увы, один и не резиновый.

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

Таких, как первый, достаточно много и присылали из разных источников... Есть подозрение, что это акцизное что-то...

0002V5ORQU6VW0B - это символы с 6 по 19 из акцизной марки
конечно это не ШК в классическом понимании, но у меня все такие коды добавлены к алкоголю
и касса (WinUKM) продает его именно по этим кодам.

Ну если база штрихкодов изначально предназначена для хранения не только штрихкодов для массового использования, а всего, чего угодно, для частных нужд, и нет проблем с размером базы, то вопросов нет, пусть остаётся как есть ;)
Я просто думал, что данная база ШК изначально подразумевала хранение только ШК.
(Для интереса - а зачем символы с 6 по 19 из марки (AlcCode, зашифрованный в base64) хранить на он-лайн севисе? Эта касса хранит базу данных и работает с ней тоже онлайн? Любой алкоголь имеет также или EAN-13 или UPS-A, другие виды ШК на этикетках штучной алкогольной продукции не используются)

REST API неканоничный у тебя. Ну или структура данных укуренная. (%


1. Статус возвращается в HTTP заголовках. Для этого они и существуют. (;

Отсюда непонятно, почему я получаю какую-то пропертю status, когда к самому ресурсу она отношения не имеет.

2. Имена ресурсов должны быть логичными, и связи между ними должны быть ясны.

Что является ресурсом? Карточка? Хорошо. Уникальность её обеспечивается чем? Штрихкодом? Допустим. Тогда почему чтобы получить все имена товара для карточки с определённым штрихкодом, мне приходится обращаться к ресурсу "карточка" с идентификатором "имя", и ещё каким-то атрибутом (штрихкодом)? Имя, ведь, атрибут карточки (пусть даже и набор имён), а не отдельный ресурс. Да и вообще, связи между ресурсами name, class и, видимо, count и producer неочевидны. Да и вообще, почему они представлены отдельными ресурсами, а не атрибутами карточки?
Из этой лапши вытекает третий косяк:

3. Пополнение классификатора выполняется в нарушение стандартов REST

POST-запрос создаёт новый ресурс (определённого типа). В твоей же имплементации один пост запрос к определённому УРЛУ создаёт сразу несколько разных ресурсов. Приведённый здесь пример должен был бы создать только классификатор с уникальным урлом, но, получается, что там происходит создание (а на самом деле - дополнение/апдейт, причём не через PUT) кучки ресурсов. Вообще моск взрывает.


Считаю, что в текущем виде твой апи даже не RESTful. Максимум - RESTlike.

Стандарта REST API не существует. Отсюда каждый делает REST-like, что сделал и я. Как понял, так и сделал. Переделывать не буду, бо народ уже прикрутил.
По статусам - кому-то удобно не в хедер смотреть, а в пропертю.
Я, в конце концов, не программист и заморачиваться мне некогда, надо семью кормить, а тут еще PHP7 и хакеры-киддисы обострились по весне. Сделал, если что неудобно - говорите, если нарушил стандарты и это кому-то мешает, давайте стандарт ;)
Поскольку стандарта нет, то сделал, как было понятно мне, это работает в древовидном варианте. И работает, быстро и понятно без чтения больших листов по RESTful-вариантам. Страница генерится за 2-3 мсек.