Найти бы пакетик в Django чтобы было что-то вроде файрвола. При нескольких запросов в определенный промежуток времени выдавало бы каптчу. Исключая поисковиков, конечно.

cloudflare

cloudflare не защищает онособо от краулинга информации

http://stackoverflow.com/questions/23361057/django-comparing-old-and-new-field-value-before-saving?answertab=votes#tab-top ну вот тут сделано

Да это может сработать. Но если после init до save было много логики, какая-нибудь сложная форма и модель с множеством FK, в этом случае потенциально оно может не верно сработать, если в другом процессе уже кто-то изменил статус. Лучше бы конечно изменение статуса проверять непосредственно перед save.

Да это может сработать. Но если после init до save было много логики, какая-нибудь сложная форма и модель с множеством FK, в этом случае потенциально оно может не верно сработать, если в другом процессе уже кто-то изменил статус. Лучше бы конечно изменение статуса проверять непосредственно перед save.

Переопредлеть save в модели всегда можно и тогда не будет никаких вообще проблем.

Хотя конечно тоже не гарантия.

извиняюсь за глупый вопрос, просто с REST не довелось работать. Вот если у меня API на получение данных - мне понятно, я сделал запрос, получил, например, json. А если я хочу сделать запрос на создание записи, что в ответ мне должно прийти?

идешник или вернет эту запись

Вопрос про REST вообще или DRF?

идешник или вернет эту запись

это четкое требование в REST архитектуре?

про REST вообще

извиняюсь за глупый вопрос, просто с REST не довелось работать. Вот если у меня API на получение данных - мне понятно, я сделал запрос, получил, например, json. А если я хочу сделать запрос на создание записи, что в ответ мне должно прийти?

почитай спецификацию swagger

это почти стандарт

http://swagger.io/specification/

почитай спецификацию swagger

спасибо, пойду гляну

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

мне больше нравится идеология внутренних статусов ответа

http код может быть 200|404|500

в случае 500 что нибудь такое

{ "status": "error", "code": "50008", "message": "Not enough balance on account" }

Не понятное поведение рест фреимворка есть сериализатор class ItemSerializer(serializers.ModelSerializer): class Meta: model = Item fields = ('id', 'title', 'description' ) class ItemViewSet(viewsets.ReadOnlyModelViewSet): serializer_class = ItemSerializer queryset = Item.objects.active() permission_classes = (permissions.IsAuthenticated,) почему при запросе /api/Items/ при пустом queryset выдается json вида {'title: '', 'description': ''} ?

там есть функция

которая либо выдает значение либо notFound

прост не помню как называется

посмотри django api

мне больше нравится идеология внутренних статусов ответа

если создаётся какой-либо объект - код ответа 201

тут два варианта, Саш

внутри могут быть любые коды

либо у тебя за коды отвечает http

либо приложение

мне больше нравится, когда сервер отвечает 200 - во всех успешных случаях

у HTTP нет достаточно большого количества кодов ответа

404 - не найден

500 - любая ошибка

воот

ну, это криво, если есть 200, 404 и 500, но нет 201

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

ну, криво когда есть 201 и нету к примеру 405

если гоняться за ними, придется все включить

если у HTTP есть код ответа, который подходит - нужно его использовать

ну так да

если есть то, что подходит - мы это включаем

400

403

мне нравится идеология белого дома

Use three simple, common response codes indicating (1) success, (2) failure due to client-side problem, (3) failure due to server-side problem: 200 - OK 400 - Bad Request 500 - Internal Server Error

(про 404 я ошибься, я имел ввиду 400)

так вот, 200 в случае успеха, 400 в случае ошибки со стороны клиента

500 в случае ошибки со стороны сервера

это best practices

все остальное по внутренним кодам

внутренний код нужен в любом случае

внешний код ответа HTTP согласно https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

на практике так не делают

на практике по другому и быть не может

на практике делают примерно так

https://github.com/WhiteHouse/api-standards

потому что API-сервер стоит за балансировщиком, которому пофиг, что у тебя нет 504 кода

и он этот код покажет, если вдруг будет нужно

ну, мы сейчас не совсем про балансировщик

если ошибку выдает балансировщик, до приложения не доходит

все API стоят за балансировщиком, ты не можешь контролировать конечный список кодов

не можешь

но включив много http кодов, ты создашь хлопоты девелоперам, которые используют API

придется обрабатывать все эти коды ошибок

когда могло бы хватит следующего

ты можешь контролировать только те коды, которые в поле ответа, а HTTP просто подстраивать по ситуации к тому, что принято, некоторые HTTP коды более распространены, некоторые менее, но тот же 201 200 400 403 404 500 и прочее - это типовые, они встречаются везде, нет смысла ограничивать их

пусть страдают)

ERROR: S client not available

ну, 201 200 400 403 404 500 можно

а вот дальше... точно не стоит

всякие 41х, 50х

на счет того же 404 - очень спорный вопрос

http коды - это коды транспортного уровня

ну вот допустим

ты выше писал о том, что у тебя там некий ограниченный список и тебе хватит, но не получится сделать его ограниченным, там всегда будет вероятность, что какой-нибудь балансирвщик/прокси вернёт такой код, которого нет в API

у меня метод GET /api/v1/cars/{id}

что ты отдашь в случае если машина по этому id не найдена?

есть куча причин, почему её может не быть

у каждого может быть свой код ошибки

внутри тела ответа

ок, допустим, ее просто нет

по такому айди

ты отдашь 404 или в теле напишешь?

я отдам 404 И напишу в теле

ок, следующий вопрос

разработчик спутал, вместо GET /api/v1/cars/{id} отправил на GET /api/v1/car{id}

отдавать 200 когда больше подходит 201 - это небрежность

а такого метода нет, как ему ответишь?

согласно коду состояний

так такого метода же нет, это тоже будет 404ая?

будет 400

потому что Bad Request

почему?

потому что такого метода нет

400 bad request гласит следующее - The request could not be understood by the server due to malformed syntax.

запрос не понятен

можешь 405

404 Not found гласит - The server has not found anything matching the Request-URI.

Method Not Allowed

405 гласит вообще другое