Почему нам нужно что-то большее, чем HTTP ПОЛУЧАЮТ, ПОМЕЩАЮТ, POST?
Если вам нужен простой, но эффективный подход, Sif Embedding отлично подойдет. Он усредняет вектор слов в предложении и удаляет его первый главный компонент. Это намного превосходит усреднение векторов слов. Код доступен онлайн здесь . Вот основная часть:
svd = TruncatedSVD(n_components=1, random_state=rand_seed, n_iter=20)
svd.fit(all_vector_representation)
svd = svd.components_
XX2 = all_vector_representation - all_vector_representation.dot(svd.transpose()) * svd
Где all_vector_representation - среднее вложение всех предложений в ваш набор данных.
Существуют и другие сложные подходы, такие как ELMO , Transformer и т. Д.
14 ответов
[REST] [1] подход использует POST, ПОЛУЧИТЕ, ПОМЕСТИТЕ и УДАЛИТЕ для реализации правил CRUD для веб-ресурса. Это - простой и опрятный способ выставить объекты запросам в сети. Это - веб-сервисы без издержек.
Просто для уточнения семантические различия. Каждая операция довольно отличается. Точка должна иметь хорошие методы HTTP, которые имеют четкие, отличные значения.
POST создает новые объекты. URI не имеет никакого ключа; это принимает тело сообщения, которое определяет объект. SQL Вставляет. [Редактирование, В то время как нет никакой технической причины POST, чтобы не иметь никакого ключа, остальные люди, предлагает сильно, чтобы, чтобы POST имел отличное значение, как СОЗДАЮТ, это не имело ключа.]
ДОБЕРИТЕСЬ получает существующие объекты. URI может иметь ключ, зависит от того, делаете ли Вы, одиночный элемент ДОБИРАЮТСЯ, или список ДОБИРАЮТСЯ. Выбор SQL
ПОМЕСТИТЕ обновляет существующий объект. URI имеет ключ; Это принимает тело сообщения, которое обновляет объект. Обновление SQL.
УДАЛИТЕ удаляет существующий объект. URI имеет ключ. SQL Удаляет.
Можно ли обновить запись с POST вместо ПОМЕЩЕННОГО? Не представляя некоторую неоднозначность. Глаголы должны иметь однозначные эффекты. Далее, POST, URI не имеет никакого ключа, где ПОМЕЩЕНО должен иметь ключ.
Когда я POST, я ожидаю СОЗДАННЫЕ 201. Если я не получаю это, что-то неправильно. Точно так же, когда я ПОМЕСТИЛ, я ожидаю 200 хорошо. Если я не получаю это, что-то неправильно.
Я предполагаю, что Вы могли настоять на некоторой неоднозначности, где POST делает или POST или ПОМЕЩЕННЫЙ. URI должен отличаться; также связанное сообщение могло отличаться. Обычно остальные, люди берут пример с SQL, где ВСТАВЛЯЮТ и ОБНОВЛЕНИЕ, являются различными глаголами.
Вы могли сделать случай, который должно вставить ОБНОВЛЕНИЕ, если запись не существует или обновляет, если запись действительно существует. Однако это более просто, если ОБНОВЛЕНИЕ означает ОБНОВЛЕНИЕ и отказ обновить средства, что-то неправильно. Секретная нейтрализация для ВСТАВКИ делает операцию неоднозначной.
Если Вы не создаете интерфейс RESTful, то это типично, чтобы только использовать, ДОБИРАЮТСЯ, и POST для получают и создают/обновляют. Распространено иметь различия URI или различия в содержимом сообщения, чтобы различать POST и ПОМЕСТИТЬ, когда человек нажимает, отправляют на форме. Это, однако, не очень чисто, потому что Ваш код должен определить, находитесь ли Вы в случае POST=create или случае POST=update.
POST не имеет никаких гарантий безопасности или idempotency. Это - одна причина ПОМЕЩЕННОГО, и УДАЛИТЕ — и ПОМЕЩЕННЫЙ и УДАЛИТЕ, идемпотент (т.е. 1+N, идентичные запросы имеют тот же конечный результат как всего 1 запрос).
ПОМЕЩЕННЫЙ используется для установки состояния ресурса в данном URI. Когда Вы отправляете запрос POST к ресурсу в конкретном URI, тот ресурс не должен быть заменен содержанием. Самое большее это должно быть добавлено к. Поэтому POST не является идемпотентом — в случае добавления СООБЩЕНИЙ, каждый запрос добавит к ресурсу (например, добавит новое сообщение к дискуссионному форуму каждый раз).
УДАЛИТЕ используется для проверки, что ресурс в данном URI удален из сервера. POST не должен обычно использоваться для удаления за исключением случая подачи запроса для удаления. Снова, URI ресурса, к которому Вы были бы POST в этом случае, не должен быть URI для ресурса, который Вы хотите удалить. Любой ресурс, для которого Вы POST к является ресурсом, который принимает, что ОТПРАВЛЕННЫЕ данные добавляют к себе, добавьте к набору, или обработать некоторым другим способом.
ГОЛОВА используется, если все, о чем Вы заботитесь, является заголовками ПОЛУЧИТЬ запроса, и Вы не хотите тратить впустую пропускную способность на фактическое содержание. Это хорошо иметь.
Одним словом:
idempotency
Еще в нескольких словах:
СТАНЬТЕ = в безопасности + идемпотент
ПОМЕЩЕННЫЙ = идемпотент
УДАЛИТЕ = идемпотент
POST = никакой сейф или идемпотентный
'Идемпотент' просто означает, что можно сделать это много раз, и это будет всегда делать точно то же самое.
Можно переиздать ПОМЕЩЕННЫЙ (обновление) или УДАЛЯТЬ запрос так много раз, как Вы хотите, и это будет иметь тот же эффект каждый раз, когда однако желаемый эффект изменит ресурс, таким образом, это не будут считать 'безопасным'.
Запрос POST должен создать новый ресурс с каждым запросом, означая, что эффект будет отличаться каждый раз. Поэтому POST не считают безопасным или идемпотентным.
Методам нравится, ДОБИРАЮТСЯ, и ГОЛОВА просто операции чтения и поэтому считаются 'безопасными', а также идемпотентными.
Это - на самом деле довольно важное понятие, потому что оно обеспечивает стандартный/последовательный способ интерпретировать транзакции HTTP; это особенно полезно в контексте защиты.
Никто не отправил вид ответа, который я искал так, я попытаюсь суммировать точки сам.
"УСПОКОИТЕЛЬНЫЕ веб-сервисы" чтения раздела "Overloading POST" главы 8: "Если Вы хотите обойтись без ПОМЕЩЕННЫЙ и УДАЛИТЬ в целом, это СОВЕРШЕННО УСПОКОИТЕЛЬНО для представления безопасной работы на ресурсах через, ДОБИРАЮТСЯ, и все другие операции через перегруженный POST. Выполнение этого нарушает мою Ориентированную на ресурс Архитектуру, но это соответствует менее строгим правилам REST".
Короче говоря, замена ПОМЕЩАЛА/УДАЛЯЛА в пользу POST, делает API тяжелее, чтобы считать и ПОМЕСТИТЬ/УДАЛИТЬ вызовы, больше не идемпотент.
Почему нам нужны больше, чем POST? Это позволяет данным течь оба пути, итак, почему ДОБРАЛСЯ бы быть необходимым? Ответ является в основном тем же что касается Вашего вопроса. Путем стандартизации основных ожиданий различных методов другие процессы могут лучше знать, что сделать.
Например, прошедшие прокси кэширования могут иметь лучший шанс выполнения корректной вещи.
Думайте о ГОЛОВЕ, например. Если прокси-сервер знает то, что ГОЛОВА имеет в виду затем, что он может обработать результат предыдущего, ЗАСТАВЛЯЮТ запрос предоставлять надлежащий ответ на ГЛАВНЫЙ запрос. И это может знать, что POST, ПОМЕСТИТЕ и УДАЛИТЕ, не должен кэшироваться.
Не все hosters не поддерживают ПОМЕЩЕННЫЙ, УДАЛЯЮТ.
Я задал этот вопрос, в идеальном мире у нас будут все глаголы, но....:
ГОЛОВА действительно полезна для определения, на что установлены часы данного сервера (с точностью до в течение 1 секунды или сетевой круговой задержки, какой бы ни больше). Это является также большим для получения кавычек Футурамы от Slashdot:
~$ curl -I slashdot.org HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 05:35:13 GMT Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 SLASH_LOG_DATA: shtml X-Powered-By: Slash 2.005001227 X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank. Cache-Control: private Pragma: private Connection: close Content-Type: text/html; charset=iso-8859-1
Для ЗАВИХРЕНИЯ, -I опция для выполнения ГЛАВНОГО запроса. Для получения текущей даты и время данного сервера просто сделайте
curl -I $server | grep ^Date
Ограничить неоднозначность, которая будет допускать лучшее/легче повторное использование нашей простой пчелы REST.
Использование веб-приложений ДОБИРАЕТСЯ, и POST позволяют пользователям создавать, просматривать, изменять и удалять свои данные, но делать так на слое выше команд HTTP, первоначально созданных в этих целях. Одна из идей позади REST является возвратом к исходному намерению дизайна сети, посредством чего существуют определенные операции HTTP для каждого глагола CRUD.
Кроме того, команда HEAD может использоваться для улучшения пользовательского опыта для (потенциально больших) загрузок файла. Вы называете ГОЛОВУ, чтобы узнать, как большой ответ будет, и затем звоните, ДОБИРАЮТСЯ для фактического получения содержания.
Вы могли использовать, только ДОБИРАЮТСЯ и POST, но затем Вы терпите неудачу на части точности и ясности, которые ПОМЕЩАЮТ и УДАЛЯЮТ, приносят. POST является подстановочной операцией, которая могла означать что-либо. Поведение ПОМЕЩЕННОГО и DELETE очень хорошо определяется. При размышлении об управлении ресурсами, API затем ПОЛУЧАЕТ, ПОМЕСТИЛ и УДАЛЯЕТ, вероятно, покрытие 80%-90% необходимой функциональности. При ограничении себя для ПОЛУЧЕНИЯ и POST затем, к 40%-60% API получают доступ с помощью плохо указанного POST.
Посмотрите следующую ссылку для иллюстративного примера. Это также предлагает один способ использовать ОПЦИИ http метод, который еще не был обсужден здесь.
Существуют http расширения как WebDAV, которые требуют дополнительный функционально.
ПОЛУЧИТЕ, ПОМЕСТИТЕ, УДАЛИТЕ, и POST пережитки с эры, когда второкурсники думали, что веб-страница могла быть уменьшена до нескольких hoighty-toity принципов.
В наше время большинство веб-страниц является составными объектами, которые содержат некоторых или все эти примитивные операции. Например, страница могла иметь формы для просмотра или обновления информации о клиенте, которая, возможно, охватывает много таблиц.
Я обычно использую $ _REQUEST [] в php, не действительно заботясь, как информация прибыла. Я принял бы решение использовать, ПОЛУЧАЮТ или ПОМЕЩАЮТ методы на основе эффективности, не лежание в основе (нескольких) парадигмы.
Война веб-сервера с более ранних дней, вероятно, вызвала его.
В HTTP 1.0, записанном в 1996, были, только ДОБИРАЮТСЯ, НАПРАВЛЯЮТСЯ, и POST. Но поскольку Вы видите в Приложении D, поставщики начали добавлять свои собственные вещи. Так, для хранения HTTP совместимым они были вынуждены сделать HTTP 1.1 в 1999.
Однако HTTP/1.0 не достаточно учитывает эффекты иерархических прокси, кэширования, потребности в постоянных соединениях или виртуальных хостов. Кроме того, быстрое увеличение не полностью реализованных приложений, называя себя "HTTP/1.0" требовало изменения версии протокола для двух связывающихся приложений для определения истинных возможностей друг друга.
Эта спецификация определяет протокол, называемый "HTTP/1.1". Этот протокол включает более строгие требования, чем HTTP/1.0 для обеспечения надежной реализации его функций.