Выклік Сервернай метад на рэсурс у RESTful Шляхі

Майце на ўвазе, у мяне ёсць элементарнае разуменне REST. Скажам, у мяне ёсць гэты URL:

http://api.animals.com/v1/dogs/1/

А цяпер я хачу, каб сервер зрабіць сабачы брэх. Толькі сервер ведае, як гэта зрабіць. Скажам, я хачу, каб запусціць яго на працу CRON, што робіць сабаку брахаць кожныя 10 хвілін на ўсё астатняе вечнасць. Што гэта выклік выглядае? Я накшталт хачу зрабіць гэта:

URL запыту:

ACTION http://api.animals.com/v1/dogs/1/

У целе запыту:

{"action":"bark"}

Перад тым, як злавацца на мяне робіць мой уласны метад HTTP, дапамагчы мне і даць мне лепшае ўяўленне аб тым, як я павінен выклікаць метад на боку сервера ў RESTful чынам. :)

<�Моцны> змянілася для ўдакладненне

Некаторыя дадатковыя тлумачэнні вакол таго, што робіць метад «кара». Вось некаторыя варыянты, якія могуць прывесці да рознаму структураваных выклікаў API:

  1. кара проста пасылае па электроннай пошце dog.email і ня запісвае нічога.
  2. кара пасылае па электроннай пошце dog.email і прырашчэння dog.barkCount на 1.
  3. кара стварае новую «кару» запіс з запісам bark.timestamp, калі кара адбылася. Гэта таксама павялічвае dog.barkCount на 1.
  4. Кара запускае сістэмную каманду, каб выцягнуць апошнюю версію кода сабакі ўніз ад Github. Затым ён адпраўляе тэкставае паведамленне dog.owner кажучы ім, што новы код сабакі знаходзіцца ў вытворчасці.
116
@Kirk якія вашыя думкі аб новых адказах? Ёсць усё, што вы ўсё яшчэ хочаце ведаць, але не разглядаліся ні ў адным з іх? Я быў бы больш чым шчаслівы зноў змяніць свой адказ, калі ён можа быць больш карысным.
дададзена аўтар Jordan, крыніца
@RaymondHettinger PATCH можа быць мэтазгодным. Я растлумачу, чаму да канца маёй адказаць .
дададзена аўтар Jordan, крыніца
@RaymondHettinger чыя практыка <�я> дэ-факта </я> стандартуе POST? Усе стандартныя інтэрфейсы RPC, якія я бачыў ідэнтыфікаваць рэсурс па арганізацыі (не RESTful), супраць URI, таму сапраўдны адказ прыярытызацыі RPC канвенцыі павінны быць нетрадыцыйным ў любым выпадку, пра які я думаю, абвяргаецца значэнне звычайнага RPC: адзін з'яўляецца уяўленнем або супярэчлівай , Вы ніколі не можаце ісці <�я> няправільна </я> з POST, як гэта комплекснае для апрацоўкі дадзеных, але ёсць і больш канкрэтныя метады. Астатнія сродкі наймення рэсурсаў і апісанне змяненняў у іх стане, не называючы дзяржаўныя зменамі парадку. PATCH і POST абодва апісваюць змены стану.
дададзена аўтар Jordan, крыніца
Цікава адзначыць, што даданне шчадротаў, здаецца, прыцягваюць горшыя адказы, чым першапачаткова была ;-) Пры ацэнцы адказаў памятаеце, што: 1) Спецыфікацыя для HTTP дзеясловаў выключаюць любы выбар акрамя POST. 2) REST не мае нічога агульнага са структурай URL - гэта агульны спіс контрсил (без грамадзянства, кэшируемого, слоістага, адзінага інтэрфейсу і г.д.), чым раіцца выгадамі (маштабаванасць, надзейнасць, бачнасць і г.д.). 3) Бягучая практыка (напрыклад, з дапамогай POST ў RPC спецыфікацыі) козыры definitionalists, якія робяць ўверх свае ўласныя правілы API. 4) Астатняй патрабуе адзінага інтэрфейсу (у адпаведнасці з HTTP спецыфікацыі).
дададзена аўтар Raymond Hettinger, крыніца
PATCH б не падыходзілі для прырашчэння <�я> dog.barkCount </я> адзін. POST метад для адпраўкі электроннай пошты, стварэнне новай кары запісу, выконваючы каманды для загрузкі з Github або запуску тэкставага паведамлення. @Jordan, ваша чытанне пластыру RFC з'яўляецца вобразным, але некалькі разыходзіцца з намерам яго ў якасці варыянту PUT для мадыфікацыі частковага рэсурсу. Я не думаю, што вы дапамагаеце Ору прыдумляючы нетрадыцыйным паказаннямі HTTP спецыфікацыі, а не прызнаючы стандартную практыку выкарыстання POST для аддаленых выклікаў працэдур.
дададзена аўтар Raymond Hettinger, крыніца

8 адказы

Навошта імкнуцца да RESTful дызайне?

У RESTful прынцыпаў <�моцны> прынесці асаблівасці, якія робяць вэб-сайты лёгка (для выпадковага чалавека карыстальнік для "сёрфінг" іх) <�моцны> да распрацоўкі вэб-сэрвісы API , таму яны лёгка праграмісту выкарыстоўваць. REST не з'яўляецца добрым, таму што гэта адпачынак, гэта добра, таму што гэта добра. І гэта добра, таму што ў асноўным гэта <�моцны> проста .

Прастата просты HTTP (без SOAP канверты і одностенная URI перагружаных POST паслугі), то, што <�моцны> некаторыя з іх могуць выклікаць "адсутнасць магчымасцяў" , з'яўляецца на самай справе <�моцны> найбольшай сілы . Адразу, HTTP просіць Вас ёсць адрасаванне і безграмадзянства : два асноўных праектных рашэнняў, якія падтрымліваюць HTTP маштабуецца да сённяшніх мега-сайтаў (і мега-паслуг).

Але REST ня срэбра bulltet: <�моцны> Часам RPC-стыль ( "Remote Procedure Call" - такія, як SOAP) <�моцны> можа быць мэтазгодным , а часам і іншыя патрэбы маюць прыярытэт над годнасці Web. Гэта нармальна. Тое, што мы не вельмі падабаецца <�моцны> Залішне складанасць . Занадта часта праграміст ці кампанія прыносіць у службах RPC-стылі для працы, што просты стары HTTP можа апрацоўваць толькі штраф. Эфект у тым, што HTTP зводзіцца да транспартнага пратаколу для вялізнага карыснай нагрузкі XML, які тлумачыць, што «на самай справе» адбываецца (а не URI або метад HTTP даць падказку пра яго). У выніку службы занадта складаныя, немагчыма адладжваць, і не будзе працаваць, калі вашы кліенты не маюць дакладнай налады у якасці распрацоўніка, прызначанага.

Same way a Java/C# code can be not object-oriented, just using HTTP does not make a design RESTful. One may be caught up in the rush of thinking about his services in terms of actions and remote methods that should be called. No wonder this will mostly end up in a RPC-Style service (or a REST-RPC-hybrid). The first step is to think different. A RESTful design can be achieved in many ways, one way (the simplest, some might say) is to think of your application in terms of resources, not actions:

  • Замест таго, каб думаць у тэрмінах дзеянняў ( «зрабіць пошук месцаў на карце»),
  • Падумайце, з пункту гледжання вынікаў гэтага дзеяння ( «спіс месцаў на карце, якая адпавядае крытэры пошуку").

Я пайду на прыкладах ніжэй. (Іншы ключавы аспект REST з'яўляецца выкарыстанне HATEOAS - я не чысціце яго тут, але я пра гэта гаварыць хутка на іншую пасаду </а>.)

Пра першы дызайне

Давайце паглядзім на прапанаванай канструкцыі:

ACTION http://api.animals.com/v1/dogs/1/

Па-першае, мы не павінны разгледзець пытанне аб стварэнні <�моцны> новы HTTP дзеяслоў ( ACTION ). Наогул кажучы, гэта <�ет> непажаданыя па некалькіх прычынах:

  • (1) Given only the service URI, how will a "random" programmer know the ACTION verb exists?
  • (2) if the programmer knows it exists, how will he know its semantics? What does that verb mean?
  • (3) what properties (safety, idempotence) should one expect that verb to have?
  • (4) what if the programmer has a very simple client that only handles standard HTTP verbs?
  • (5) ...

Зараз давайце <�моцны> разгледзець магчымасць выкарыстання POST (я буду абмяркоўваць, чаму ніжэй, проста паверце мне на слова цяпер):

POST /v1/dogs/1/ HTTP/1.1
Host: api.animals.com

{"action":"bark"}

Гэта можа ОК ... але <�моцны> толькі калі :

  • {"action":"bark"} was a document; and
  • /v1/dogs/1/ was a "document processor" (factory-like) URI. A "document processor" is a URI that you'd just "throw things at" and "forget" about them - the processor may redirect you to a newly created resource after the "throwing". E.g. the URI for posting messages at a message broker service, which, after the posting would redirect you to a URI that shows the status of the message's processing.

Я не ведаю шмат пра вашай сістэме, але я ўжо трымаў заклад, абодва не так:

  • {"action":"bark"} is not a document, it actually is the method you are trying to ninja-sneak into the service; and
  • the /v1/dogs/1/ URI represents a "dog" resource (probably the dog with id==1) and not a document processor.

Так што ўсё, што мы ведаем зараз, што вышэй канструкцыя не так RESTful, але што гэта менавіта? <�Моцны> Што так дрэнна пра яго? У асноўным, гэта дрэнна, таму што гэта складаны URI са складанымі значэннямі. Вы нічога не можаце з гэтым зрабіць выснову. Як праграміст ведаць, сабака ёсць Кара дзеянне, якое можа быць таемна заваренного з POST у яго?

Распрацоўка API выклікаў на ваша пытанне ў

Так што давайце скараціць да пагоні і паспрабаваць распрацаваць гэтыя брэша RESTfully, думаючы <�моцны> з пункту гледжання рэсурсаў . Дазвольце мне працытаваць

RESTful Web Services кнігі:

<�Р> А POST запыт з'яўляецца спробай стварыць новы рэсурс з існуючага   адзін. Існуючы рэсурс можа быць бацькам новага адзін у   структура дадзеных сэнс, то, як корань дрэва з'яўляецца бацькам усіх   яго ліставыя вузлы. Або існуючы рэсурс можа быць адмысловы «завод»   рэсурс, адзінай мэтай якой з'яўляецца стварэнне іншых рэсурсаў.   прадстаўленне адпраўляецца разам з POST запыт апісвае пачатковае   стан новага рэсурсу. Як і PUT, а POST запыт не трэба   ўключае ў сябе прадстаўленне на ўсіх.

Пасля апісання вышэй, мы можам бачыць, што <�моцны> кара можа быць змадэляваныя як <�моцны> а subresource з сабака (так як < код> кара змяшчаецца ўнутры сабакі, гэта значыць, кара «брахаў» <�моцны> па сабака).

З гэтага развагі мы ўжо атрымалі:

  • The method is POST
  • The resource is /barks, subresource of dog: /v1/dogs/1/barks, representing a bark "factory". That URI is unique for each dog (since it is under /v1/dogs/{id}).

Цяпер кожны выпадак вашага спісу мае пэўныя паводзіны.

1. Кара проста пасылае электронную пошту dog.email і запісвае нічога.

Па-першае, брэша (адпраўка па электроннай пошце) сінхронны або асінхронны задачы? Па-другое робіць Кара запыт патрабуе якога-кольвек дакумэнту (па электроннай пошце, можа быць) ці гэта пустое?


1,1 кара пасылае электронную пошту dog.email і ня запісвае нічога (як сінхроннае задачы)

Гэты выпадак вельмі просты. Выклік да брэша Завод рэсурсаў дае кару (электронная пошта, адпраўленая) адразу і адказ (калі ён працуе нармальна ці не) даецца адразу:

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

(entity-body is empty - or, if you require a **document**, place it here)

200 OK

Як яна запісвае (змены) нічога, 200 OK дастаткова. Гэта паказвае, што ўсё прайшло, як чакалася.


1,2 кара пасылае электронную пошту dog.email і ня запісвае нічога (як асінхроннай задачы)

У гэтым выпадку кліент павінен мець магчымасць адсочваць задачы Кара . Задача Кара затым павінен быць рэсурс з гэта ўласны URI.:

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

{document body, if needed;
NOTE: when possible, the response SHOULD contain a short hypertext note with a hyperlink
to the newly created resource (bark) URI, the same returned in the Location header
(also notice that, for the 202 status code, the Location header meaning is not
standardized, thus the importance of a hipertext/hyperlink response)}

202 Accepted
Location: http://api.animals.com/v1/dogs/1/barks/a65h44

Такім чынам, кожны Кара нагляду за. Затым кліент можа выдаць GET у карой URI ведаць гэта бягучы стан. Можа быць, нават выкарыстоўваць DELETE , каб адмяніць яго.


2. Кара пасылае электронную пошту dog.email , а затым павялічвае dog.barkCount на 1

Гэта адзін можа быць складаней, калі вы хочаце, каб дазволіць кліенту ведаць, сабака рэсурс атрымлівае змены:

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

{document body, if needed; when possible, containing a hipertext/hyperlink with the address
in the Location header -- says the standard}

303 See Other
Location: http://api.animals.com/v1/dogs/1

У гэтым выпадку месца Намер Header з'яўляецца, каб кліент ведаў, што ён павінен глядзець на сабака . З HTTP RFC аб 303 :

<�Р> Гэты метад існуе ў першую чаргу, каб дазволіць выхад   <�Моцнага> POST -активированного скрыпт для перанакіравання агента карыстальніка да абранага рэсурсу.

Калі задача з'яўляецца асінхронным, а Кара subresource патрэбен гэтак жа, як 1.2 сітуацыі і 303 павінен быць вернуты ў GET. ../ брэша/Y , калі задача будзе завершана.


3. Кара стварае новы « Кара » запіс з bark.timestamp запісы, калі кара адбылося. Гэта таксама павялічвае dog.barkCount на 1.

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

(document body, if needed)

201 Created
Location: http://api.animals.com/v1/dogs/1/barks/a65h44

У дадзеным выпадку Кара гэта ствараецца за кошт запыту, таму статус 201 Створана ўжываецца.

Калі стварэнне з'яўляецца асінхронным, а 202 Accepted патрабуецца ( як HTTP RFC кажа ) замест гэтага.

Отметка зэканомленай частка кара рэсурсу і можа быць атрымана з дапамогай GET да яго. Абноўленая сабака можа быць «дакументаваны» у тым, што GET сабак/X/брэша/Y а.


4. Кара запускае сістэмную каманду, каб выцягнуць апошнюю версію кода сабакі ўніз ад Github. Затым ён адпраўляе тэкставае паведамленне dog.owner , кажучы ім, што новы код сабака знаходзіцца ў вытворчасці.

Фармулёўка гэтага з'яўляецца тое складаным, але гэта ў значнай ступені з'яўляецца просты асінхроннай задача:

POST /v1/dogs/1/barks HTTP/1.1
Host: api.animals.com
Authorization: Basic mAUhhuE08u724bh249a2xaP=

(document body, if needed)

202 Accepted
Location: http://api.animals.com/v1/dogs/1/barks/a65h44

Затым кліент будзе выдаваць GET s ў /v1/Сабакі/1/брэша/a65h44 , каб даведацца бягучы стан (калі код быў разабраны, яго электронная пошта была накіроўваецца ўладальніку і да таго падобнае). Кожны раз, калі змяняецца сабака, а 303 з'яўляецца appliable.


Завяршаючы

Цытаванне Рой Філдынг :

<�Р> Адзіная REST патрабуе метадаў з'яўляецца тое, што яны раўнамерна   вызначаны для ўсіх рэсурсаў (гэта значыць, так што пасярэднікі не павінны   ведаць тып рэсурсу для таго, каб зразумець сэнс   запыт). </р>

У прыведзеных вышэй прыкладах, POST раўнамерна прызначаны. Гэта прымусіць сабаку « Кара ». Гэта не бяспечна (гэта значыць кара аказвае ўплыў на рэсурсы), ні идемпотентная (кожны запыт дае новы Кара ), які адпавядае POST дзеяслоў добра.

Праграміст будзе ведаць: а POST у брэша дае Кара . Коды стану адказу (таксама з целам аб'екта і загалоўкамі пры неабходнасці) выконваць работу па растлумачэнню таго, што змянілася і як кліент можа і павінен працягвацца.

<�Суб> Заўвага: Першасныя крыніцы былі выкарыстаны: " RESTful Web Services " кнігі, HTTP RFC і Рой Філдынг блог . </суб>




<�Моцны> Edit:

Пытанне і, такім чынам, адказ змяніўся зусім няшмат, бо яны ўпершыню былі створаны. <�Моцны> арыгінальны пытанне пытанне аб дызайне URI, як:

ACTION http://api.animals.com/v1/dogs/1/?action=bark

Ніжэй прыводзіцца тлумачэнне таго, чаму гэта не з'яўляецца добрым выбарам:

Як кліенты кажуць сервер ШТО РАБІЦЬ з дадзенымі з'яўляецца Метад інфармацыі .

  • RESTful вэб-сэрвісы перадачы інфармацыі метад ў метадзе HTTP.
  • Тыповы RPC-Style і SOAP паслуга трымаць у Іх ці загалоўку сутнасці цела і HTTP.

WHICH PART of the data [the client wants the server] to operate on is the scoping information.

  • RESTful сэрвісы выкарыстоўваюць URI. SOAP/RPC-Style паслугі зноў выкарыстоўваць загалоўкі цела аб'екта і HTTP.

У якасці прыкладу возьмем кампаніі Google URI http://www.google.com/search?q=DOG . Там, інфармацыя метаду д = САБАКІ GET і інфармацыя прадметнага ахопу /пошук ?.

Карацей кажучы:

  • У RESTful архітэктуры , інфармацыя метад пераходзіць у метад HTTP.
  • У Рэсурсазберагальныя арыентаваныя архітэктуры , інфармацыя агляднай пераходзіць у URI.

І правіла:

<�Р> Калі метад HTTP не адпавядае інфармацыі метады, паслуга не RESTful. Калі інфармацыя аб агляднай не ў URI, сэрвіс не арыентаваныя на прыродныя рэсурсы.

Вы можаце паставіць "кара" "дзеянне" ў URL (ці ў целе аб'екта) і выкарыстаць POST . Няма праблем там, яна не працуе, і можа быць самы просты спосаб зрабіць гэта, <�моцны>, але гэта не RESTful .

Каб захаваць свае паслугі на самай справе RESTful, вы, магчыма, прыйдзецца зрабіць крок назад і думаць пра тое, што вы сапраўды хочаце зрабіць тут (якія наступствы гэта будзе мець на рэсурсы).

Я не магу казаць пра вашых канкрэтных патрэбаў бізнесу, але дазвольце мне даць вам прыклад: Разгледзім RESTful сэрвіс заказу, дзе заказы на URI, як example.com/order/123 .

Зараз выкажам здагадку, што мы хочам, каб адмяніць заказ, як мы будзем рабіць гэта? Адзін можа ўзнікнуць спакуса думаць, што гэта "Адмена» «дзеянне» і яго дызайн як example.com/order/123?do=cancel.

Гэта не RESTful, як мы казалі вышэй. Замест гэтага мы можам PUT новае ўяўленне парадку з адмененага элемент адпраўлены True :

PUT /order/123 HTTP/1.1
Content-Type: application/xml


    ...
    true
    ...

And that's it. If the order can't be canceled, a specific status code can be returned. (A subresource design, like POST /order/123/canceled with the entity-body true may, for simplicity, also be available.)

У вашым канкрэтным выпадку, вы можаце паспрабаваць нешта падобнае. Такім чынам, у той час як сабака брэша, напрыклад, GET у /v1/Сабакі/1/ можа ўключаць у сябе такую ​​інфармацыю (напрыклад, <�брэх > True </брэх> ) . Ці ... калі гэта занадта складана, аслабіць ваша RESTful патрабаванні і прытрымлівацца POST .

абнаўленне:

Я не хачу, каб зрабіць адказ занадта вялікім, але гэта зойме некаторы час, каб павесіць агаляючы алгарытм (у дзеянне ) як набор рэсурсаў. Замест таго, каб думаць у тэрмінах дзеянняў ( «зрабіце пошук месцаў на карце» ), трэба думаць у тэрмінах вынікаў гэтага дзеяння ( "спіс месцаў на карта адпаведнасці пошуку крытэрыі ").

Вы можаце знайсці сабе вяртацца да гэтага кроку, калі вы выявіце, што ваш дызайн не адпавядае уніфікаваны інтэрфейс пратаколу HTTP.

Запыт пераменнага з'яўляецца агляднай інфармацыі , але зрабіць <�моцнага> не пазначае новыя рэсурсы (/пост? LANG = гп відавочна <�моцны> той жа рэсурс як /пост? LANG = Jp , проста іншае прадстаўленне). Хутчэй за ўсё, яны выкарыстоўваюцца для перадачы <�моцны> кліент стан (напрыклад, старонка = 10 , так што стан не захоўваецца на серверы ;? <�Код> LANG = гп </код > таксама прыклад тут) або <�моцны> ўваходныя параметры да алгарытмічныя рэсурсы (/пошук? д = сабакі , /сабакі? код = 1 ). Зноў жа, не асобныя рэсурсы.

HTTP дзеясловы (метады) ўласцівасці:

Іншы момант, які ясна паказвае дзеянне = нешта у URI ня RESTful, з'яўляецца ўласцівасцю HTTP дзеясловаў:

  • GET and HEAD are safe (and idempotent);
  • PUT and DELETE are idempotent only;
  • POST is neither.

Safety: A GET or HEAD request is a request to read some data, not a request to change any server state. The client can make a GET or HEAD request 10 times and it's the same as making it once, or never making it at all.

Idempotence: An idempotent operation in one that has the same effect whether you apply it once or more than once (in math, multiplying by zero is idempotent). If you DELETE a resource once, deleting again will have the same effect (the resource is GONE already).

<�суб> POST не з'яўляецца ні бяспечным, ні идемпотентная. Стварэнне двух аднолькавых POST запыты на «фабрычнай» рэсурсу, верагодна, прывядзе ў двух падначаленых рэсурсаў, якія змяшчаюць той жа інфармацыя. З перагружанай (метад у URI або сутнасць цела) POST , усе стаўкі выключаны. </Суб>

Абодва гэтыя ўласцівасці маюць важнае значэнне для поспеху пратаколу HTTP (больш ненадзейных сетак!): Колькі разоў вы абнаўлялі ( GET ) старонкі, не чакаючы, пакуль яна не будзе цалкам загружана?

Стварэнне спісу Дзеянне і змясціць яго ў URL відавочна парушае кантракт метадаў HTTP. Зноў жа, гэтая тэхналогія дазваляе, вы можаце гэта зрабіць, але гэта не RESTful дызайн.

224
дададзена
Няма Якаў, метад або падпраграма не з'яўляецца не вызначаецца (любой часткі) URI. <�Я> мішэнь запыту задаецца URI. Што рабіць з рэсурсам вызначаны як мага лепш з дапамогай метаду з даступных, і калі гэтага не дастаткова, то цела запыту.
дададзена аўтар Nicholas Shanks, крыніца
Вялікае тлумачэнне, я галасаваў, але загаловак размешчаных не павінен выкарыстоўвацца ў 202 Accepted адказу. Гэта, здаецца, няправільнае тлумачэнне, што многія людзі робяць з RFC. Праверце stackoverflow.com/questions/26199228/…
дададзена аўтар Delmo, крыніца
Гэта мае сэнс для 202/Месцы выкарыстання. Што тычыцца «цела аб'екта" і "дакумент", ваша выраз прымусіла мяне думаць, што яны былі дзве розныя рэчы (напрыклад, «цела аб'екта пуста - ці, калі вам патрабуецца дакумент , змесціце яго тут») , Асабіста я толькі калі-небудзь выкарыстаў тэрмін «цела запыту». Я мяркую, што я толькі што даведаўся два сінонімаў :). Ура!
дададзена аўтар maximedupre, крыніца
Я думаю, што 201 лепш, чым 202 пры адпраўцы Месцазнаходжанне <�код /> загаловак. Ад MDN: «Загаловак Размяшчэнне адказу паказвае URL для перанакіравання на старонку, ён толькі забяспечвае сэнс, калі служыў з 3xx (уключэньне) або 201 (створаны) адказ статусу.».
дададзена аўтар maximedupre, крыніца
У чым розніца паміж «целам аб'екта» і «дакументам»?
дададзена аўтар maximedupre, крыніца
@maximedupre Від. Я б перафразаваць «Гэта толькі дае значэнне» для «Гэта толькі частка стандарту». Як заявіў Рой , Месцазнаходжанне можа быць выкарыстаны з 202 , яго проста што ён не мае стандартныя паводзіны для гэтага кода стану і, такім чынам, вы павінны пераканацца, што адказ зразумелы, выкарыстоўваючы іншыя сродкі, такія, як гіпертэксту, які змяшчае спасылку. Іншымі словамі: стандарт не сказаць, што такое Месцазнаходжанне азначае для 202, але гэта не forbit выкарыстоўваць яго для 202. Калі вы выкарыстоўваеце яго, вы павінны растлумачыць карыстачу, што гэта значыць. Я спрабаваў паказаць, што ў адказ ...
дададзена аўтар acdcjunior, крыніца
Я меў на ўвазе "сутнасць-цела" і "дакумент" сінонімы. Вы не згодныя? (Акрамя таго, Месцазнаходжанне рэч, вы не згодныя з тым, што я сказаў у папярэднім каментары?)
дададзена аўтар acdcjunior, крыніца
@CMCDragonkai мы сапраўды абмяркоўвалі некалькі выпадкаў, а не толькі базавы (гл «змяніць для асвятлення» часткі). Калі інфармацыя бескарысная, не захоўваць яго (гл выпадкі 1.1: адказ проста 200-OK, каб запытваюць ведаць сервер зразумеў запыт). І, вядома, любы чалавек можа загубіць прынцыпы і рэалізацыю, як ён/яна хоча, і яна будзе працаваць - улічваючы, вядома, што ўсе часткі, якія ўдзельнічаюць у курсе таго, што URL-адрас і метады азначаюць, што ёсць, што новы «пратакол "ёсць.
дададзена аўтар acdcjunior, крыніца
@maximedupre Так, «сутнасць-цела», як у «запаўняльнік» для магчымага дакумента ў запыце HTTP/адказ. У фразе вы згадваеце, можа быць, «цела аб'екта» будзе фактычна сінонім «слот, дзе вы размяшчае дакумент». Ва ўсякім выпадку, я звычайна выкарыстоўваю іх як узаемазаменныя, кантэкст дапамагае зрабіць яго больш выразным. Калі вы хочаце спытаць пра тэрміне у спецыфікацыі я павінен паглядзець яго, таму што я на самой справе не ведаю, з верхняй частцы маёй галавы дакладна.
дададзена аўтар acdcjunior, крыніца
@Delmo пагадзіўся. Хоць я адчуваю, <�я> не павінен з'яўляецца занадта моцным. Як заявіў Рой, Месцазнаходжанне можа выкарыстоўвацца з 202, яго толькі, што ён не мае стандартныя паводзіны для гэтага статусу кода і, такім чынам, вы павінны пераканацца, што адказ зразумелы, выкарыстоўваючы іншыя сродкі, такія як гіпертэксту, які змяшчае гіперспасылка. Я дадаў заўвагу да адказу, каб паказаць на гэта. Дзякуй за галовы!
дададзена аўтар acdcjunior, крыніца
@ JarosławKończak ды, множны лік больш паказана, я выправіў, дзе гэта неабходна. дзякуй
дададзена аўтар acdcjunior, крыніца
Справа аб спробе быць RESTful выкарыстоўвае HTTP так, як гэта лепш за ўсё распрацаваны, каб быць (прычына яна была настолькі паспяховай). Можна было б зрабіць гэта проста GET у /брэша , але гэта сапраўды аптымальны? Я вазьму ў вас каментарый: гэта хтосьці выконвае GET у /брэша сапраўды чакае выпусціць новы Кара ? Або яны разлічваюць атрымаць інфармацыю пра брэша? У рэшце рэшт, спрабуючы «быць спакойным» спрабуе выкарыстоўваць HTTP ў лепшым выглядзе, а не толькі ў якасці транспартнага пратаколу.
дададзена аўтар acdcjunior, крыніца
Адказ нас у курсе. Гэта крыху доўга, таму што дбайнае тлумачэнне, здавалася, неабходна ( «Майце на ўвазе, у мяне ёсць элементарнае разуменне REST.»). Гэта быў выгляд барацьбы, каб зрабіць яго максімальна ясна поўным, наколькі гэта магчыма. Спадзяюся, што гэта карысна ў некаторым родзе.
дададзена аўтар acdcjunior, крыніца
@JacobStevens ОП змяніў пытанне крыху, так што я павінен абнавіць свой адказ, каб зрабіць яго больш прамым (праверце арыгінальнага пытання , можа быць, вы зразумееце, што я маю на ўвазе). Я згодны з POST «забеспячэнне блока дадзеных ... да працэсу апрацоўкі», але розніца сапраўды, што блок <�б> дадзеныя , а не блок дадзеных і працэдуры (дзеянне, метад каманды) будзе выконвацца на потым. Гэта значыць POST перагрузкі і POST перагрузка канструкцыі RPC-Style, ня RESTful.
дададзена аўтар acdcjunior, крыніца
Гэта выдатны answear, мне вельмі дапамог. Цікава аб адным: часам вы карыстаецеся /кара/, а часам /брэша/ у URI фрагмента. Напрыклад. Вы POST на /v1/Сабакі/1/брэша , але ў вас ёсць .../Сабакі/1/кара/a65h44 у загалоўку Location ў адказы. Рэсурс павінен быць заўсёды ў множным ліку, ці не так?
дададзена аўтар Jarosław Kończak, крыніца
Гэта вялікая праца, каб зрабіць нешта сапраўды проста. Ці варта ствараць гэтыя абстракцыі проста так што вы можаце прытрымлівацца RESTful прынцыпаў, калі вы проста хочаце, каб выклікаць простае дзеянне. Што рабіць, калі гэтыя дзеянні фактычна не належыць нікому або любы бацькоўскі рэсурс? А што адбываецца, калі вы атрымліваеце брэх? Ці азначае гэта, што вам заўсёды трымаць справаздачу аб усіх брэша, якія адбываюцца нават тады, калі гэтая інфармацыя бескарысная?
дададзена аўтар CMCDragonkai, крыніца
Я мяркую логіка дзеянняў/метад будзе размешчаны на сэрвэры, інакш што б мэта выкліку быць? У выпадку, калі вы апісаць, я згодны, што не будзе добрым дызайнам. Але метад або падпраграма, якая выконвае дзеянне будзе паказаная ў URI (што з'яўляецца яшчэ адной прычынай, чаму рэсурс дзеянні пазначаецца як дзеяслоў ў канцы URL карысна і RESTful, хоць шматлікія раяць супраць яго).
дададзена аўтар Jacob Stevens, крыніца
Я бяру разлад з ідэяй, што выклік дзеянні на сэрвэры, пазначаны як дзеянне ў URL, ня RESTful. POST быў распрацаваны для <�я> "забеспячэнне блока дадзеных ... да працэсу апрацоўкі " . Здаецца, шмат людзей адрозніваць рэсурсы ад дзеянняў, але на самой справе дзеянні толькі тып рэсурсу.
дададзена аўтар Jacob Stevens, крыніца

I answered earlier, but this answer contradicts my old answer and follows a much different strategy for coming to a solution. It shows how the HTTP request is built from the concepts that define АДПАЧЫНАК and HTTP. It also uses PATCH instead of POST or PUT.

Ён праходзіць праз астатнія абмежаванні, то кампаненты HTTP, то магчымым рашэнні.

АДПАЧЫНАК

АДПАЧЫНАК is a set of constraints intended to be applied to a distributed hypermedia system in order to make it scalable. Even to make sense of it in the context of remotely controlling an action, you have to think of remotely controlling an action as a part of a distributed hypermedia system -- a part of a system for discovering, viewing, and modifying interconnected information. If that's more trouble than it's worth, then it's probably no good to try to make it АДПАЧЫНАКful. If you just want a "control panel" type GUI on the client that can trigger actions on the server via port 80, then you probably want a simple RPC interface like JSON-RPC via HTTP requests/responses or a WebSocket.

But АДПАЧЫНАК is a fascinating way of thinking and the example in the question happens to be easy to model with a АДПАЧЫНАКful interface, so let's take on the challenge for fun and for education.

АДПАЧЫНАК is defined by four interface constraints:

<�Р> ідэнтыфікацыя рэсурсаў; маніпуляванне рэсурсаў праз прадстаўлення; самоописательные паведамлення; і, гипермедиа як рухавік стану прыкладання. </р>

You ask how you can define an interface, meeting these constraints, via which one computer tells another computer to make a dog bark. Specifically, you want your interface to be HTTP, and you don't want to discard the features that make HTTP АДПАЧЫНАКful when used as intended.

Давайце пачнем з першага абмежаванні: <�моцны> рэсурс ідэнтыфікацыі .

<�Р> Любая інфармацыя, якая можа быць імем можа быць рэсурсам: дакумент або малюнак, часовай службы (напрыклад, «надвор'е сёння ў Лос-Анджэлесе»), калекцыя іншых рэсурсаў, невіртуальных аб'ект (напрыклад, чалавек), і гэтак далей.

Так што сабака з'яўляецца рэсурсам. Ён павінен быць ідэнтыфікаваны.

<�Р> Больш дакладна, рэсурс <�я> R з'яўляецца ў часе той ці іншай функцыі прыналежнасці <�я> М <�суб> R </суб> ( т ), які для часу <�я> т карты да набору аб'ектаў або значэнняў, якія эквівалентныя. Значэння ў наборы могуць быць прадстаўлення рэсурсаў і/або ідэнтыфікатары рэсурсаў . </Р>

Вы мадэль сабака, узяўшы набор ідэнтыфікатараў і ўяўленняў і кажуць, што яны ўсе звязаны адзін з адным ў дадзены момант часу. У цяперашні час, давайце выкарыстоўваць ідэнтыфікатар «сабака # 1». Гэта падводзіць нас да другой і трэцяй абмежаванняў: <�моцны> ўяўленне рэсурсу і <�моцны> самоописание .

АДПАЧЫНАК components perform actions on a resource by using a representation to capture the current or intended state of that resource and transferring that representation between components. A representation is a sequence of bytes, plus representation metadata to describe those bytes.

Ніжэй прыводзіцца паслядоўнасць байт, захапіўшы намечанае стан сабакі, то ёсць уяўленне, мы хочам быць звязаныя з ідэнтыфікатарам «сабака # 1» (звярніце ўвагу, што яна ўяўляе сабой толькі частка дзяржавы, паколькі ён не лічыць імя сабакі, здароўе або нават у мінулым кары):

<�Р> Гэта было брахаць кожныя 10 хвілін, так як час было ажыццёўлена гэта змяненне стану, і будзе працягвацца да бясконцасці.

Мяркуецца, быць прымацаванымі да метададзеных, якія апісваюць яго. Гэтыя метададзеныя могуць быць карысныя:

<�Р> Гэта англійскае заяву. Ён апісвае частка меркаванага стану. Калі атрымана некалькі разоў, дазваляюць толькі першы, каб мець эфект.

Нарэшце, давайце паглядзім на чацвёрты абмежаванне: <�моцны> HATEOAS .

АДПАЧЫНАК ... views an application as a cohesive structure of information and control alternatives through which a user can perform a desired task. For example, looking-up a word in an on-line dictionary is one application, as is touring through a virtual museum, or reviewing a set of class notes to study for an exam. ... The next control state of an application resides in the representation of the first requested resource, so obtaining that first representation is a priority. ... The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations.

In a АДПАЧЫНАКful interface, the client receives a resource representation in order to figure out how it should receive or send a representation. There must be a representation somewhere in the application from which the client can figure out how to receive or send all representations it should be able to receive or send, even if it follows a chain of representations to arrive at that information. This seems simple enough:

Кліент запытвае ўяўленне рэсурсу, ідэнтыфікаваны ў якасці хатняй старонкі; у адказ ён атрымлівае ўяўленне, якое змяшчае ідэнтыфікатар кожнай сабакі кліент можа захацець. Кліент здабывае ідэнтыфікатар з яго і пытаецца службу, як ён можа ўзаемадзейнічаць з выяўленай сабакам, а сэрвіс кажа кліент можа паслаць англійскае заяву, якое апісвае частка меркаванага стану сабакі. Затым кліент адпраўляе такую ​​заяву і атрымлівае паведамленне аб паспяховым або паведамленне пра памылку.

HTTP

HTTP implements АДПАЧЫНАК constraints as follows:

resource identification: URI

resource representation: entity-body

self-description: method or status code, headers, and possibly parts of the entity-body (e.g. the URI of an xml schema)

HATEOAS: hyperlinks

Вы вырашылі http://api.animals.com/v1/dogs/1 у якасці URI. Давайце выкажам здагадку, што кліент атрымаў ад гэтага нейкі старонкі сайта.

Давайце выкарыстоўваць гэта цела аб'екта (значэнне Далей з'яўляецца адзнака аб час, а значэнне 0 азначае «калі запыт атрыманы»):

{"barks": {"next": 0, "frequency": 10}}

Зараз нам патрэбен метад. PATCH адпавядае «частка меркаванага стану» апісанне мы вырашылі на:

<�Р> Метад заплацім запытвае, што мноства змен, апісаных ў запыце асобы быць ужытыя да рэсурсу, ідэнтыфікаванай Request-URI. </Р>

І некаторыя загалоўкі:

To indicate the language of the entity-body: Content-Type: application/json

To make sure it only happens once: If-Unmodified-Since:

І ў нас ёсць запыт:

PATCH /v1/dogs/1/ HTTP/1.1
Host: api.animals.com
Content-Type: application/json
If-Unmodified-Since: 
[other headers]

{"barks": {"next": 0, "frequency": 10}}

У выпадку поспеху, кліент павінен атрымаць 204 </а> код стану ў адказ, або 205 калі ўяўленне /v1/сабакі/1/ змянілася, каб адлюстраваць новы графік брэх.

У выпадку няўдачы, ён павінен атрымаць 403 і карыснае паведамленне чаму.

It is not essential to АДПАЧЫНАК for the service to reflect the bark schedule in a representation in response to GET /v1/dogs/1/, but it would make the most sense if a JSON representation included this:

"barks": {
    "previous": [x_1, x_2, ..., x_n],
    "next": x_n,
    "frequency": 10
}

Лячыць хрон як дэталь рэалізацыі, што сервер хавае ад інтэрфейсу. Гэта прыгажосць агульнага інтэрфейсу. Кліент не павінен ведаць, што робіць сервер за кулісамі; усё гэта клапоціцца аб тым, што служба разумее і рэагуе на запытаныя змены стану.

6
дададзена

Большасць людзей выкарыстоўваюць POST для гэтай мэты. Ён падыходзіць для выканання «небяспечнай або неидемпотентной аперацыі, калі ніякага іншага метад HTTP не ўяўляецца мэтазгодным».

API-інтэрфейсы, такія як XMLRPC выкарыстоўваць POST для запуску дзеянняў, якія могуць выконвацца адвольны код , «Дзеянне» ўключана ў дадзеных POST:

POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181

<?xml version="1.0"?>

   examples.getStateName
   
      
         41
         
      
   

RPC з'яўляецца прыклад прыведзены, каб паказаць, што пост з'яўляецца звычайным выбарам HTTP дзеясловаў для серверных метадаў. Вось Рой Філдынг думкі аб POST - ён даволі шмат кажа, што гэта RESTful выкарыстоўваць метады HTTP, як паказана.

Звярніце ўвагу, што само па сабе RPC не вельмі RESTful, таму што гэта не рэсурс, арыентаваны. Але калі вам трэба безграмадзянства, кэшаванне, або іерархічнае, гэта не цяжка зрабіць адпаведныя пераўтварэнні. См http://blog.perfectapi.com/2012/opinionated -RPC-Апіс-VS-заспакойлівай-APIs/ для прыкладу.

4
дададзена
Я думаю, што вы б UrlEncode ў Params ня паставіць яго ў радку запыту
дададзена аўтар tacos_tacos_tacos, крыніца
Ці будзе гэта выглядаць наступным чынам: POST api.animals.com/v1/dogs/1 /? = дзеянне кары
дададзена аўтар Kirk Ouimet, крыніца
калі вы будзеце прытрымлівацца парадаў у гэтым адказе, мець на ўвазе, што ў выніку API не будзе RESTful.
дададзена аўтар Nicholas Shanks, крыніца
Гэта не RESTful <�б>, таму што HTTP ўсталёўвае URL у якасці ідэнтыфікатара рэсурсу і URL з /RPC2 не робіць нічога, каб ідэнтыфікаваць рэсурс - гэта ідэнтыфікуе серверную тэхналогію. Замест гэтага выкарыстоўваецца имяМетода , каб паспрабаваць «ідэнтыфікацыя» «рэсурс», - але нават тады яна не прыносіць карысці ад назоўніка/дзеяслова адрозненні; толькі «verb 'падобныя рэчы тут methodCall . Гэта як «зрабіць дзяржава-імя-пошук» замест «атрымаць дзяржаўны імя_файла» - апошні робіць так значна больш сэнсу.
дададзена аўтар Jordan, крыніца
+1 для спасылак; вельмі інфарматыўныя і эксперымент «ўпарты RPC» вынаходлівы.
дададзена аўтар Jordan, крыніца
@Kirk Так, але з адным невялікім змяненнем, падзенне канчатковай касой рысы: POST api.animals.com/v1/dogs1?action=bark
дададзена аўтар Raymond Hettinger, крыніца

POST is the HTTP method designed for

Забеспячэнне блока дадзеных ... да працэсу апрацоўкі

Серверныя метады апрацоўкі без CRUD адлюстраваных дзеянняў з'яўляецца тое, што рой Філдынг прызначаны з REST, так што вы там добра, і таму POST было зроблена быць не идемпотентная. <�Код> POST будзе працаваць з большасцю вывешваць дадзеныя на боку сервера метады апрацоўкі інфармацыі.

Тым не менш, у вашай сабакі-лай сцэнар, калі вы хочаце, на боку сервера, кара павінна быць выканана праз кожныя 10 хвілін, але па нейкай прычыне патрэбен трыгер зыходзіць ад кліента, PUT будзе служыць мэты лепш, з-за яго идемпотентности. Ну, строга па гэтым сцэнары няма ніякага відавочнага рызыкі множных запытаў POST выклікае ваша сабаку мяўкаць замест гэтага, але ў любым выпадку гэта мэта два падобных метадаў. Мой адказ на аналагічнае пытанне SO </а> можа быць карысным для вас.

2
дададзена
PUT супраць POST ўсё аб URL. Трэці пункт пасля таго, як 9.6 PUT кажа мэта два метаду з'яўляецца так PUT URL спасылаецца на тое, што павінна быць <�б> замяніць па змесце кліента і POST URL спасылаецца на тое, што павінна <�б> працэс ўтрыманне кліента, аднак ён хоча.
дададзена аўтар Jordan, крыніца

Больш раннія змены некаторых адказаў прапанавалі выкарыстоўваць RPC. Вам не трэба глядзець на RPC, як гэта з'яўляецца Цалкам магчыма рабіць тое, што вы хочаце, у той час як прытрымліваючыся абмежаванняў REST.

Па-першае, то і не давайце параметры дзеянняў у URL. У URL вызначае , што вы падаеце заяву дзеянні, і параметры запыту з'яўляюцца часткай URL. Гэта варта разглядаць выключна як назоўніка http://api.animals.com/v1/dogs/1/?action=bark гэта іншы рэсурс -. розныя назоўнік - да http://api.animals.com/v1/dogs/1/ . [Нотабене Аскер выдаліла ? Дзеянне = карой URI ад пытання.] Напрыклад, параўнайце http://api.animals.com/v1/dogs/?id=1 да http://api.animals.com/v1/dogs/?id=2 . Розныя рэсурсы, якія адрозніваюцца толькі радкі запыту. Такім чынам, дзеянне вашага запыту, калі ён не адпавядае непасрэдна да bodyless існуючага тыпу метаду (TRACE, OPTIONS, HEAD, GET, DELETE і г.д.) павінны быць вызначаны ў целе запыту.

Затым вырашыце, калі дзеянне « идемпотентная », гэта азначае, што ён можа быць паўтораны без адмоўнага эфекту (гл наступнага пункта для больш explanaton). Напрыклад, усталёўваючы значэнне ісціна можа быць паўтораная, калі кліент не ўпэўнены ў тым, што жаданы эфект адбылося. Яны пасылаюць запыт зноў і значэнне застаецца верным. Даданне 1 да ліку ня идемпотентное. Калі кліент адпраўляе каманду add1, не ўпэўнены, што яна працавала, і адпраўляе яго зноў, зрабіў сервер дадаць адзін ці два? Пасля таго, як вы вызначылі, што вы знаходзіцеся ў лепшым становішчы, каб выбраць паміж PUT і POST для вашага метаду.

Идемпотентный азначае, запыт можа быць паўтараецца без змены выніку. Гэтыя эфекты не ўключаюць у сябе рэгістрацыю і іншыя дзеянні адміністратара такіх сервераў. Выкарыстоўваючы свае першыя і другія прыклады, адпраўку два паведамленняў электроннай пошты і таму ж чалавеку сапраўды прыводзіць іншы стан, чым адпраўка адзін адрасы электроннай пошты (атрымальнік мае два ў сваёй паштовай скрыні, якія яны маглі б разгледзець як спам), так што я б пэўна выкарыстоўваць POST для гэтага , Калі barkCount у прыкладзе 2 прызначаны, каб быць заўважаным карыстальнікам вашага API або ўплывае на тое, што з'яўляецца кліентам-бачым, то гэта таксама тое, што б зрабіць запыт не-идемпотент. Калі гэта толькі праглядацца вамі, то ён лічыцца пратакалявання сервера і павінны ігнаравацца пры якія вызначылі idempotentcy.

І, нарэшце, вызначыць, ці з'яўляецца дзеянне, якое вы хочаце выканаць як можна чакаць, адразу ці не атрымаецца. BarkDog гэта хутка завяршае дзеянне. RunMarathon няма. Калі дзеянне адбываецца павольна, разгледзець магчымасць вяртання да 202 Accepted , з URL у целе адказу для карыстальніка апытання, каб убачыць, калі дзеянне завершана. З іншага боку, ёсць карыстальнікі POST у спіс URL, як /марафонах ў незавершаным/, а затым, калі дзеянне выконваецца, перанакіроўваць іх з незавершанага ID URL ў /марафоны-поўны/ URL.
Для канкрэтных выпадкаў # 1 і # 2, я б хост-сервера чарзе, і кліент паштовых адрасоў партыі да яго. Дзеянне не будзе SendEmails, але нешта накшталт AddToDispatchQueue. Сервер можа затым апытвае чаргу, каб убачыць, калі ёсць якой-небудзь адрас электроннай пошты ў чаканні, і адпраўляць паведамленні электроннай пошты, калі ён знаходзіць які-небудзь. Затым ён абнаўляе чаргу, каб паказаць, што ў чаканні дзеянняў у цяперашні час выконваюцца. Вы бы іншы URI, які паказвае кліенту бягучага стану чарзе. Для таго, каб пазбегнуць двайны адпраўкі паведамленняў электроннай пошты, сервер можа таксама весці часопіс, які ён паслаў гэты ліст, і праверыць кожны адрас супраць таго, каб пераканацца, што ён ніколі не пасылае два на той жа адрас, нават калі вы POST той жа спіс двойчы чаргу.

Пры выбары URI для чаго-небудзь, паспрабуйце думаць пра яго, як вынік, не дзеянне. Напрыклад, google.com/search?q=dogs паказвае вынікі з пошуку словы «сабак». Ён не necessarilly выканаць пошук.

Выпадкі # 3 і # 4 з вашага спісу таксама ня идемпотентны дзеянні. Вы прапануеце, што розныя прапанаваныя эфекты могуць паўплываць на дызайн API. Ва ўсіх чатырох выпадках я хацеў бы выкарыстаць такі ж самы інтэрфейс, як і ўсе чатыры змены «сусветнага дзяржавы.»

1
дададзена
Скажам, дзеянне маслабойку праз гіганцкую чаргу электроннай пошты і адправіць паведамленне на кучу людзей. Гэта идемпотентная? Идемпотентны дзеянні для PUT або POST?
дададзена аўтар Kirk Ouimet, крыніца
@kirk я пашырыў свой адказ.
дададзена аўтар Nicholas Shanks, крыніца

REST з'яўляецца стандартным рэсурсам арыентаваных, гэта не дзеянне прывада, як RPC будзе.

Калі вы хочаце, каб ваш сервер Кара , вы павінны глядзець на розныя ідэі, як JSON-RPC </а > або ў WebSockets сувязі.

Кожны паспрабаваць захаваць яго RESTful пацерпіць няўдачу, на мой погляд: вы можаце аформіць POST з Дзеянне параметр, вы не ствараеце якіх-небудзь новых рэсурсаў, але, як вы можаце мець пабочныя эфекты , вы бяспечней.

1
дададзена
Як я апісваю ў мой адказ , вы можаце ў REST няяўна прымусіць сервер выканаць дзеянне, папрасіўшы яго сказаць, з цяпер, «ваша дзеянне было завершана», у той час як RPC заснаваны на ідэі проста просіць сервер выканаць дзеянне. І выдатны сэнс, гэтак жа, як імператыў і дэкларатыўнае праграмаванне і мае сэнс.
дададзена аўтар Jordan, крыніца
POST быў распрацаваны для <�я> "забеспячэнне блока дадзеных ... да працэсу апрацоўкі " . Здаецца, шмат людзей адрозніваць рэсурсы ад дзеянняў, але на самой справе дзеянні толькі тып рэсурсу. Выклік рэсурсу дзеянняў на сэрвэры па-ранейшаму адзіны інтэрфейс, кэшуецца, модульнай і маштабуецца. Гэта таксама асобы без грамадзянства, але гэта можа быць парушана, калі кліент прызначаны для рэагавання. Але выклік «VOID метад» на сэрвэры, што Roy Філдынг прызначаны з REST .
дададзена аўтар Jacob Stevens, крыніца

Калі мы выкажам здагадку, брэх з'яўляецца ўнутранай/залежным/субом рэсурсу, які спажывец можа дзейнічаць далей, то мы маглі б сказаць:

POST http://api.animals.com/v1/dogs/1/bark

нумар сабакі 1 брэша

GET http://api.animals.com/v1/dogs/1/bark

вяртае апошнюю змяняць час кары

DELETE http://api.animals.com/v1/dogs/1/bark

не ўжываецца! так што ігнараваць яго.

1
дададзена
Гэта толькі RESTful, калі вы лічыце, /v1/Сабакі/1/Кара , каб быць рэсурсам <�я> сам па сабе і POST , каб быць апісанне як ўнутраны стан гэтага рэсурсу павінна змяніцца. Я лічу, што гэта мае сэнс толькі, каб разгледзець /v1/Сабакі/1/ у якасці рэсурсу і паказаць у целе аб'екта, што яна павінна брахаць.
дададзена аўтар Jordan, крыніца
ммм .. ну, гэта рэсурс, які вы можаце змяніць свой стан. Паколькі вынік змены яго стану робіць шум, ня робіць яго менш рэсурсаёмістым! Вы глядзіце на Bark як дзеяслоў (які), таму вы не можаце лічыць гэта рэсурс. Я гляджу на яго як залежны рэсурс, які яго стан можа быць зменена, і так як яго стан булева, я не бачу ніякіх падстаў казаць пра гэта ў целе аб'екта. Гэта толькі маё меркаванне.
дададзена аўтар bolbol, крыніца

See my new answer -- it contradicts this one and explains АДПАЧЫНАК and HTTP more clearly and accurately.

Вось <�моцны> рэкамендацыя , што здараецца АДПАЧЫНАКful, але, вядома, не адзіны варыянт. Для таго, каб пачаць брахаць, калі служба атрымлівае запыт:

POST /v1/dogs/1/bark-schedule HTTP/1.1
...
{"token": 12345, "next": 0, "frequency": 10}

token is an arbitrary number that prevents redundant barks no matter how many times this request is sent.

next indicates the time of the next bark; a value of 0 means 'ASAP'.

Кожны раз, калі вы GET/v1/Сабакі/1/Кара-графік , вы павінны атрымаць нешта накшталт гэтага, дзе <�ет> т падчас апошняга кары і і з'яўляецца <�ет> т + 10 хвілін:

<�Код> { "апошні": т, "побач": і}

Я настойліва рэкамендую вам выкарыстоўваць той жа URL, каб запытаць кару, які вы выкарыстоўваеце, каб даведацца пра бягучы стан брэху сабакі. Гэта не важна, каб адпачыць, але ён падкрэслівае акт змены раскладу.

Адпаведны код стану, верагодна, 205 . Я сабе кліент, які глядзіць на бягучым графіку, POST s да таго ж URL, каб змяніць яго, і ўказанне ад службы, каб даць Пераліку другога погляд, каб даказаць, што ён быў зменены ,

тлумачэнне

АДПАЧЫНАК

Forget about HTTP for a moment. It's essential to understand that a resource is a function that takes time as input and returns a set containing identifiers and representations. Let's simplify that to: a resource is a set R of identifiers and representations; R can change -- members can be added, removed, or modified. (Though it's bad, unstable design to remove or modify identifiers.) We say an identifier that is an element of R identifies R, and that a representation that is an element of R represents R.

Скажам, R з'яўляецца сабака. Вам давядзецца вызначыць R , як /v1/сабак/1 . (Значэнне /v1/Сабакі/1 з'яўляецца членам R ). Гэта толькі адзін з многіх спосабаў, можна вызначыць R . Акрамя таго, можна вызначыць R , як /v1/Сабакі/1/Рэнтгенаўскія прамяні і як /v1/Руфус .

Як вы ўяўляеце R ? Можа быць, з фатаграфіяй. Можа быць, з наборам рэнтгенаўскіх прамянёў. Ці, можа быць, з указаннем даты і часу, калі <�ет> R апошняя брахаў. Але памятайце, што ўсе гэтыя ўяўленні той жа рэсурс . <�Код>/v1/Сабакі/1/Рэнтген з'яўляецца ідэнтыфікатарам аднаго і таго ж рэсурсу, які прадстаўлены адказ на пытанне «калі зрабіў R апошняя карай?»

HTTP

Множныя прадстаўлення рэсурсу не вельмі карысна, калі вы не можаце звярнуцца да аднаго вы хочаце. Вось чаму HTTP карысны: ён дазваляе падключыць ідэнтыфікатары уяўленняў . Гэта значыць, гэта спосаб для службы, каб атрымаць URL і вырашыць, якое ўяўленне служыць кліенту.

Прынамсі, гэта тое, што GET робіць. <�Код> PUT у асноўным інверсіяй GET вы PUT ўяўленне <�ет> г ў URL, калі вы хочаце для будучага < код> GET запыты да гэтага URL, каб вярнуцца <�ет> г , з некаторымі магчымымі перакладамі як JSON ў HTML.

POST is a looser way of modifying a representation. Think of there being display logic and modification logic that are counterparts to each other -- both corresponding to the same URL. A POST request is a request for the modification logic to process the information and modify any representations (not just the representation located by the same URL) as the service sees fit. Pay attention to the third paragraph after 9.6 PUT: you're not replacing the thing at the URL with new content; you're asking the thing at the URL to process some information and intelligently respond in the form of informative representations.

У нашым выпадку, мы пытаем логіку мадыфікацыі ў /v1/Сабакі/1/Кара-графіка (які з'яўляецца аналагам логікі адлюстравання, які кажа нам, калі ён у апошні раз раўнуў, і калі ён будзе побач кара) апрацоўваць нашу інфармацыю і змяніць некаторыя ўяўленні адпаведна. У адказ на будучы GET s, логіка адлюстравання, адпаведныя адным і тым жа URL будзе сказаць нам, што сабака цяпер брэх, як мы хочам.

Падумайце аб хрон як дэталь рэалізацыі. HTTP здзелак у прагляд і змяненне уяўленняў. З гэтага моманту, сэрвіс паведаміць кліенту, калі сабака ў апошні раз раўнуў, і калі яна будзе брахаць побач. З пункту гледжання сэрвісу, які сумленны, таму што ў тыя часы адпавядаюць мінулым і запланаваным хрон працоўных месцаў.

0
дададзена