Разлика между версии на „REST“

правопис
(правопис)
 
'''Услугата REST''' ''({{lang-en|''Representational state transfer''}})'' представлява разпределителна системна рамка, базирана на [[уеб]] протоколи и технологии. Архитектурният модел Rest включва взаимодействията между сървър и клиент, осъществени по време на трансфера на данни. [[Уеб]] е най-мащабната имплементация на REST.
 
== История ==
Архитектурният стил на "REST" е разработен от [http://en.wikipedia.org/wiki/World_Wide_Web_Consortium W3C] Technical Architecture Group (TAG) едновременно със HTTP/1.1, базирано на съществуващият дизайн на HTTP/1.0. "[http://en.wikipedia.org/wiki/World_Wide_Web Word Wide Web]" представлява най - голямото осъществяване на архитектурния стил на REST.
REST - стилът обикновено се състои от [http://en.wikipedia.org/wiki/Client_(computing) клиенти] и [http://en.wikipedia.org/wiki/Server_(computing) сървъри]. Клиентите инициратинициират заявки към сървърите; сървърите преработват заявките и връщат подходящи отговори. Заявките и отговорите са създадени през прехвърляне на образа на ресурси. [http://en.wikipedia.org/wiki/Web_resource Ресурсът] може да бъде всякаква ясна и смислена концепция, която може да бъде адресирана. [http://en.wikipedia.org/wiki/Representation_(systemics) Репрезентация] на ресурс обикновено е документ, който намира сегашнoтосегашното възнамерявано състояние на ресурса.
 
Клиентът започва да изпраща заявки, когато е готов да направи преходът към ново състояние. Докато една или повече заявки са неизпълнени за клиента се смята, че е в преход. Репрезентацията на всяко приложение се състои от линкове, които могат да бъдат използвани следващия път, когато клиентът избере да направи нови официални промени.
 
== Условия ==
Архитектурният стил на "REST" прилага шест ограничителни условия, като същевременно дава свобода за дизайна и имплементацията на индивидуалните компоненти:
; [[Клиент-сървър|Клиент-сървър]]
: Клиента има право да кешира (запазва) информация, получена в отговор от сървъра, за да я преизползва при последващи заявки. За тази цел сървъра трябва имплицитно или експлицитно да е посочил дали информацията в отговора може да се кешира, за да се избегнат случаи, в които клиента получава грешна информация при бъдещи заявки. При правилно управление и използване на кеширането могат частично или напълно да се елиминират ненужни взаимодействия между клиента и сървъра, като по този начин се подобрява бързината и производителността.
; Многослойна система
: ОбикновенноОбикновено клиентът не знае дали е свързан с крайния сървър или със сървър-посредник. Сървърите-посредници подобряват ефективността, като увеличават капацитета за обработване на заявки и предоставят споделени кешове. Също така те допринасят да подобряването на сигурността.
; Код при поискване (незадължително)
: Сървърът може временно да разшири функционалността, изпращайки код, който се изпълнява директно при клиента. Например клиентски скриптове, написани на [[JavaScript]] или компилирани компоненти като Java applets.
 
Всяка разпространена хипермедийна система, съответстваща на архитектурния стил на "REST" притежава нужната производителност, мащабируемост, опростеност, гъвкавост, видимост, портативност и надеждност.
 
== RESTful API ==
RESTful уеб API (също наричано RESTful уеб service) е уеб приложение,което използва принципите на HTTP и REST. Представлява колекция от ресурси със четири дефинирани аспектa:
* Основният "URL" за уеб приложенията като http://example.com/resources/
* [http://en.wikipedia.org/wiki/Internet_media_type Internet media] типът на данните поддържани от уеб приложенията. Това най-честo е [http://en.wikipedia.org/wiki/JSON JSON], но може да бъде всеки друг валиден интeрнетИнтернет медиен тип, като се има предвид, че е валиден хипертекст стандарт.
* Операции поддържани от уеб приложението използвайки [http://en.wikipedia.org/wiki/Request_method HTTP методи] (примерно: GET, PUT, POST, или DELETE).
* Приложенията трябва да се задвижват от хипертекст.
:Имайки изображение на ресурса, клиента има достатъчно информация,с която може да променя или трие ресурсите от сървъра, в случай че има разрешението да го направи.
 
'''Самоописващи съощениясъобщения'''
:Всяко съобщение включва информация, която описва как да се обработи съощениетосъобщението.
 
'''HATEOAS (Hypermedia as the Engine of Application State)'''
* Поддръжката на Google Fusion Tables включва [https://developers.google.com/fusiontables/ RESTful API]
 
== Вижте също ==
* [http://en.wikipedia.org/wiki/RSDL RSDL] (RESTful Service Description Language)
* [http://en.wikipedia.org/wiki/Clean_URL Clean URLs]