Фильтрация в GET в RESTful

Это так скажем спецификация/рекомендация ну или что-то типо того от мужика, который все это двигает.

Разбивать на несколько запросов не всегда круто, особенно когда id — какой-нибудь хеш и у вас вообще их штук 50 вмещается в url, а POST позволил бы более адекватные объемы получить.

Фильтрация в GET в RESTful

Считайте, что клиент — это SAAS проект, и модели, это примерно как список городов, только примерно раз в 1-2 дня обновляющихся и по некоторым надо получить инфу. Номер модели содержится в товаре, но я уверен, что запрашивать такую инфу надо пачкой, а не /api/offer/777/model. Так как групповые операции с БД всегда быстрее (когда в разумных пределах выборка)

Фильтрация в GET в RESTful

Полезная информация, спасибо. Пропустил видимо её до этого.

Фильтрация в GET в RESTful

Получается зачем RESTful API, если сервис в любой момент может расшириться и GET просто не хватит при использовании фильтров. Получается, что есть вариант, при котором вам придется переписать API и вызовы. Это жесть. Не понимаю подоплеку всего этого REST.

Фильтрация в GET в RESTful

Да, пожалуй, на днях 3-4 вечера изучал rest принципы и видимо проглядел, где там описывается групповое создание ресурса, а может и нет этого в спецификации.

Фильтрация в GET в RESTful

> В POST запросе круче не будет т.к. не будет работеть кеширование
Кеширование это бесспорно круто, но как вы его контролируете? Есть ресурсы, которые нельзя кешировать, да и просто, допустим список моделей может время от времени изменятся (как и всё), а вы будете отдавать старую версию. Именно такой вариант можно разрулить коде вашего приложения — оно и будет кеш сбрасывать, если меняет инфу в табличке. Вебсерверу вы кеш вроде как так просто не сбросите.

По второму абзацу — может, но не уверен, все же групповые операции, это групповые. Плюс в условиях общедоступного API наверняка не заставите клиентов использовать все это.

p.s. Яндекс не от хорошей жизни этот случай как POST сделал, думаю api.yandex.ru/market/partner/doc/dg/reference/post-models.xml

Фильтрация в GET в RESTful

Некуда, да и REST предполагает фильтрацию в Url

Почему push после merge предлагает залить на сервер коммиты, начиная с самого первого?

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

Почему push после merge предлагает залить на сервер коммиты, начиная с самого первого?

arturgspb@arturgspb-ubuntu-desktop:~/Рабочий стол/master.2$ git remote -v 
origin	[e-mail]:dev.git (fetch)
origin	[e-mail]:dev.git (push)

arturgspb@arturgspb-ubuntu-desktop:~/Рабочий стол/master.2$ git branch -av
  master                              4630e81 *comment*
* notice_outputcontext                36cd699 *comment*
  remotes/origin/1253.m               cc7ec91 *comment*
  remotes/origin/1202          7939838 *comment*
  remotes/origin/1226          918fd28 *comment*
  remotes/origin/1251          ba29c05 *comment*
  remotes/origin/HEAD                 -> origin/master
  remotes/origin/master               4630e81 *comment*
  remotes/origin/notice_outputcontext 36cd699 *comment*
  remotes/origin/stable               a298c5a *comment*

Как хранить и работать с деньгами в коде и базе данных?

Вы только в БД эти данные обрабатываете?

Как хранить и работать с деньгами в коде и базе данных?

Мы пока на postgres тоже не испытываем. А какой язык программирования вы используете?

Как хранить и работать с деньгами в коде и базе данных?

Я использую postgresql. Проверил там — получилось, что число «999999999999999999» (это в копейках) вставилось только в int8 и money. В numeric банально не хватило места, хотя я убрал две девятки.

Money мне учтиво ставит знак доллара. Локаль, понятно. Но что если у меня много валют (я просто не в курсе как это организуется тогда)?

test=# select * from "money";
        int         |      numeric      |           money
--------------------+-------------------+---------------------------
  12345678901234599 |   123456789012345 |   $123,456,789,012,345.00
 999999999999999999 | 10000000000000000 | $9,999,999,999,999,999.99
(2 rows)

Как хранить и работать с деньгами в коде и базе данных?

Я так понимаю decimal?

Как хранить и работать с деньгами в коде и базе данных?

> Postgres, тип поля float:
Я про float и не говорю. Он вообще нигде точный не будет так как стандарт этого не предполагает. А с numeric в posgtres все в порядке и очень точно.

Как хранить и работать с деньгами в коде и базе данных?

> Потеря точности и постоянные округления, конечно.
Про какие, например, округления вы говорите? bcmath точно считает

> И весьма забавные вычисления около нуля.
Поясните, пожалуйста.

> Но при чём тут float, когда рассматриваете int и decimal?
Это я на всякий случай написал, от крикунов, которые вообще ничего не смыслят. Вы можете не обращать внимания.

Как хранить и работать с деньгами в коде и базе данных?

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

Как вы связываете Java + PHP?

Будет медленно, а в задаче я писал зачем мне

Как вы связываете Java + PHP?

По этому поводу я все понял. Хорошо. Но кто-нибудь все таки скажет что-то про соединение Java и php?

Как вы связываете Java + PHP?

Ну тогда уж скорее Redis

В чем принципиальное отличие unique (constraints) от unique index?

Ну собственно да, я пока что понял тоже самое. Просто думал — может есть какие-то подводные камни