Как указать произвольные действия при использовании HTTP 1.1 CRUD [duplicate]
Эта «ошибка» дала мне много часов работы сверхурочных! Но я начинаю видеть его потенциальное использование (но мне хотелось бы, чтобы это было во время выполнения, все еще)
Я дам вам то, что я вижу в качестве полезного примера.
def example(errors=[]):
# statements
# Something went wrong
mistake = True
if mistake:
tryToFixIt(errors)
# Didn't work.. let's try again
tryToFixItAnotherway(errors)
# This time it worked
return errors
def tryToFixIt(err):
err.append('Attempt to fix it')
def tryToFixItAnotherway(err):
err.append('Attempt to fix it by another way')
def main():
for item in range(2):
errors = example()
print '\n'.join(errors)
main()
печатает следующие
Attempt to fix it
Attempt to fix it by another way
Attempt to fix it
Attempt to fix it by another way
4 ответа
Подумайте о покупке как бизнес-объект или ресурс в словаре RESTful. При этом покупка покупки фактически создает новый ресурс. Итак:
POST /api/purchase
разместит новый порядок. Детали (пользователь, автомобиль и т. Д.) Должны ссылаться на идентификатор (или URI) внутри содержимого, отправленного по этому адресу.
Не имеет значения, что заказ автомобиля - это не просто простой INSERT в базы данных. На самом деле, REST - это не просмотр ваших таблиц базы данных как операций CRUD. С логической точки зрения вы создаете заказ (покупку), но серверная сторона может выполнять столько шагов обработки, сколько захочет.
Вы даже можете даже злоупотреблять протоколом HTTP еще больше. Используйте заголовок Location, чтобы вернуть ссылку на вновь созданный заказ, тщательно выберите коды ответов HTTP, чтобы информировать пользователей о проблемах (на сервере или на стороне клиента) и т. Д.
-
1REST - это все, что нужно для управления состоянием ресурсов, и каждая бизнес-операция должна быть сопоставлена с состоянием CRUD-операций. Если вам нужна семантика бизнес-операций hard , вам нужно перейти на SOAP-путь (SOAP - это фактически передача сообщений, но обычно организуется в операциях запроса-ответа). – Tomasz Nurkiewicz 27 July 2011 в 21:35
-
2«Покупка как ресурс» дизайн выглядит аккуратно. Что делать, если ресурс - это «пиво» .. и я хочу, чтобы сервер его выпил .. (это было для меня, я обязательно получил бы это;)) .. мы должны рассмотреть действие «пить» и т. Д. как ресурс?! .. или «пить пиво», a hard бизнес-операция?! Более серьезно, является ли дизайн RESTful рассмотрением действий в качестве ресурсов?! .. – Myobis 11 February 2013 в 00:21
-
3Как вы можете разоблачить и утвердить заказ на поставку? через службу REST? Я думаю, что @TomaszNurkiewicz прав в том, что все, что не может быть сделано аккуратно по пути CRUD, потребует операции-семантики, предоставляемой SOAP. Если "утверждение заказа на поставку" является моделью / сущностью по своему усмотрению. Например. Подтверждение POST / po (с информацией о заказе в запросе). – mydoghasworms 14 February 2014 в 08:22
-
4С точки зрения клиента REST "одобрить заказ на поставку" должно быть просто очередным обновлением заказа. Например. изменение "Утвержденный" к "истинному" и отправить обновление на сервер. Возможно, серверу понадобится выполнить проверку и, вероятно, потребуется обновить / создать множество других ресурсов. Но это проблема серверов и не должна быть видимой клиенту. – AVee 25 June 2014 в 09:19
-
5@antinome: «Предположим, что клиент знает некоторые из этих», если это так, вы не делаете REST (хотя это может быть и правда, разумное программное обеспечение!). REST был разработан для создания клиентов, которые не знают такого рода вещи, для создания клиентов, которые все еще работают, если поведение сервера меняется. То, что вы пытаетесь сделать, это классический RPC, вам нужно либо просмотреть свой подход, чтобы он соответствовал REST, либо принять, что вы делаете RPC, и используете протокол, предназначенный для RPC, например SOAP. REST очень сильно пытается не быть RPC, поэтому он никогда не будет подходящим, если вы захотите / нуждаетесь в RPC. – AVee 26 August 2014 в 12:59
То, что вы действительно делаете, это создать заказ. Таким образом, добавьте еще один ресурс для заказа и сообщения и поставьте его во время процесса заказа.
Подумайте о ресурсах, а не о вызовах методов.
Чтобы завершить заказ, вероятно, вы получите POST / api / order // полный или что-то подобное.
Я чувствую, что API REST помогает в гораздо большем количестве способов, чем просто предоставление семантики. Поэтому нельзя выбирать стиль RPC только из-за некоторых вызовов, которые, похоже, имеют больше смысла в стиле RPC. Например, google maps api, чтобы найти направления между двумя местами. Выглядит так: http://maps.googleapis.com/maps/api/directions/json?origin=Jakkur&destination=Hebbal
Они могли бы назвать это «findDirections» "(глагол) и рассматривал его как операцию. Скорее они сделали «направление» (существительное) в качестве ресурса и обработали направления поиска как запрос ресурса маршрутов (хотя внутри не могло быть никакого реального ресурса, называемого направлением, и его можно было бы реализовать бизнес-логикой, чтобы найти направления на основе параметров).
-
1Это плохой пример. В этом случае направления (все возможные направления, бесконечное число из них) - это ресурс, а параметры - только фильтры. Но вы не можете совершать «покупку», с этим, так как фильтры имеют смысл только при выполнении операций и поместить заказ или отменить его операции, которые изменяют данные – Tseng 9 October 2015 в 18:57
-
2покупка будет POST по заказу с json в теле, чтобы указать, что заказ создан. cancel будет PUT / order с json, несущим изменение состояния заказа, чтобы указать, что это идемпотентное обновление. Я все еще сталкиваюсь с операцией, которая не может быть выражена в формате ресурсов. Поэтому было бы интересно увидеть такой пример – Maruthi 4 November 2015 в 08:52
-
3@Maruthi Как бы вы выразили & quot; send_forgot_password_email & quot; используя HTTP 1.1 CRUD? – Vladimir Kornea 9 April 2018 в 11:13