Какой HTTP-глагол подходит для установки логического?

У меня есть веб-служба RESTful, которая предоставляет ресурс, который позволяет вам (зарегистрированному пользователю) нравится или не похоже на сообщение в блоге. Мой вопрос: каков RESTfully правильный способ выразить этот ресурс?Какой HTTP-глагол подходит для установки логического?

Мой первый удар выглядит следующим образом:

PUT /likes/<blog_entry_id> # marks this blog entry as liked 
DELETE /likes/<blog_entry_id> # marks this blog entry as not liked

Этот семантический, по крайней мере в соответствии с требованиями идемпотентности PUT и DELETE (то есть повторяющиеся вызовы PUT не имеют никакого эффекта, если не вперемешку с удалений, и наоборот).

Существует ли более традиционный дизайн для управления булевым HTTP-ресурсом?

источник

2011-01-18 zayyop

Я думаю, что ваш подход прекрасен и успокаивается. Вы также можете использовать POST вместо PUT.

источник

2011-01-18 11:48:48 Tarlog

Он мог, но его просьба идемпотент. Использование метода non-idempotent HTTP, когда вы делаете идемпотентный запрос, делает ваш запрос менее «видимым». –

Я думаю, что PUT также не является idempotent (не проверял это в spec, хотя, но если он идемпотент, его невозможно будет использовать для обновлений. Правильно?) Поэтому я не вижу разницы с этой точки зрения, чтобы использовать PUT или POST. Поскольку он будет «создавать как», он выглядит как POST для меня. – Tarlog

PUT является идемпотентным. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html Похоже, вы путаете «безопасный» и «идемпотентный». PUT не является «безопасным».Вы можете использовать PUT для создания вещей. –

Вам необходимо включить какой-либо идентификатор пользователя в свой URI. Используя «зарегистрированный пользователь», вы нарушаете ограничение идентификации ресурса и ограничение самоописания.

Единственная проблема заключается в том, что вы используете PUT без прохождения тела. Я никогда не видел этого раньше. Вполне возможно, что спецификация HTTP позволяет это, это немного странно.

источник

2011-01-18 12:16:57

Я думаю, что это нормально использовать «зарегистрированный пользователь». Ресурс - это запись в блоге. Кто делает «как», не является частью ресурса. Это может быть параметр в запросе или каким-то образом передан в теле (так что он будет содержаться внутри тела :) или выведен из файла cookie/header («logged in user»). – Tarlog

@Tarlog Нет, это не нормально. GET/like/13123 вернет один результат, когда вы войдете в систему и вернете другой результат: я вошел в систему. Это очень плохая идея, так как посредникам очень сложно кэшировать ответы. Это также затрудняет вам просмотр, нравится ли мне блог. –

Это происходит каждый раз. Даже на этом сайте даже в этом вопросе: ответ, который я получаю, когда я получаю URL-адрес для этого вопроса, зависит от того, вошел ли я в систему или нет. – Tarlog

Я бы отойти от использования глаголов в URL-ресурсов и использовать следующие схемы:

POST /blog/<id>/fan Отправить идентификатор пользователя и другие данные для ресурса, который вы хотите создать в рамках действий на «как». Я предположив JSON здесь, так что это может быть примером { «пользователь»: «HTTP: //..../user/34343», «метка»: 234353443}

вы могли бы использовать GET /blog/<id>/fan для получить список всех пользователей, которым нравится сообщение в блоге. Я бы, вероятно, отправил JSON-презентацию ресурса, которая упростит список этих пользователей и последует по ссылке данные подобного действия (если они есть)

, чтобы получить данные подобного действия (если есть какой-либо)

источник

2011-01-19 04:53:01

В реляционной базе данных я бы назвал это хорошим кандидатом для таблицы соединений.

 
LIKES 
----- 
id 
blog_id 
user_id 
some_other_attribute_about_this_relationship 
another_attribute 
timestamp

Так что вы создаете это, как, или вентилятор, или BlogLike или BlogFan или BlogLiker, или, вы знаете, fan_of_a_blog, если вы не в целом краткость вещи.

Так это ваши глаголы:

 
GET /likes  return a list of Likes 
POST /likes  create a new Like (payload is blog_id and user_id) 
GET /likes/id  return a specific Like resource 
PUT /likes/id  update a Like with new data 
DELETE /likes/id delete a Like

Это позволит вам задавать вопросы по обе стороны соединения. Например, нравится ли этому пользователю определенный блог? Этот блог понравился более чем трем пользователям? И т. Д.

источник

2011-03-18 03:26:53

Какой HTTP-глагол подходит для установки логического?

ответ

Смежные вопросы