REST: Разлика между версии

Изтрито е съдържание Добавено е съдържание

Линейно

Версия от 16:07, 30 април 2014

Услугата REST (Шаблон:Lang-en) представлява разпределителна системна рамка, базирана на уеб протоколи и технологии. Архитектурният модел Rest включва взаимодействията между сървър и клиент, осъществени по време на трансфера на данни. Уеб е най-мащабната имплементация на REST.

История

Архитектурният стил на "REST" е разработен от W3C Technical Architecture Group (TAG) едновременно със HTTP/1.1, базирано на съществуващият дизайн на HTTP/1.0. "Word Wide Web" представлява най - голямото осъществяване на архитектурния стил на REST. REST - стилът обикновено се състои от клиенти и сървъри. Клиентите инициират заявки към сървърите; сървърите преработват заявките и връщат подходящи отговори. Заявките и отговорите са създадени през прехвърляне на образа на ресурси. Ресурсът може да бъде всякаква ясна и смислена концепция, която може да бъде адресирана. Представяне (анг. representation) на ресурс обикновено е документ, който намира сегашното възнамерявано състояние на ресурса.

Клиентът започва да изпраща заявки, когато е готов да направи преходът към ново състояние. Докато една или повече заявки са неизпълнени за клиента се смята, че е в преход. Представянето на всяко приложение се състои от линкове, които могат да бъдат използвани следващия път, когато клиентът избере да направи нови официални промени.

Условия

Архитектурният стил на "REST" прилага шест ограничителни условия, като същевременно дава свобода за дизайна и имплементацията на индивидуалните компоненти:

Клиент-сървър: Единният интерфейс разделя клиента и сървъра. Това означава, например, че клиента не се грижи за складирането на данни. Тази задача остава изцяло за сървъра, като по този начин се подобрява портативността на клиентския код (може да се използва в различни среди). Сървърът няма връзка с потребителския интерфейс и по този начин е по-семпъл и лесен за премащабиране. Клиентът и сървърът могат да бъдат заменяни или развивани независимо един от друг, стига това да не налага промяна на единния интерфейс помежду им.
Без статус на сесията (Шаблон:Lang-en): Следващото условие е на сървъра да не се запазват статуси на сесиите. Всяка заявка от клиента, съдържа в себе си нужната информация за нейната обработка, статуси на сесии се запазват единствено при клиента.
Кеширане: Клиента има право да кешира (запазва) информация, получена в отговор от сървъра, за да я преизползва при последващи заявки. За тази цел сървъра трябва имплицитно или експлицитно да е посочил дали информацията в отговора може да се кешира, за да се избегнат случаи, в които клиента получава грешна информация при бъдещи заявки. При правилно управление и използване на кеширането могат частично или напълно да се елиминират ненужни взаимодействия между клиента и сървъра, като по този начин се подобрява бързината и производителността.
Многослойна система: Обикновено клиентът не знае дали е свързан с крайния сървър или със сървър-посредник. Сървърите-посредници подобряват ефективността, като увеличават капацитета за обработване на заявки и предоставят споделени кешове. Също така те допринасят да подобряването на сигурността.
Код при поискване (незадължително): Сървърът може временно да разшири функционалността, изпращайки код, който се изпълнява директно при клиента. Например клиентски скриптове, написани на JavaScript или компилирани компоненти като Java applets.
Единен интерфейс: Единният интерфейс между клиента и сървъра разделя и опростява архитектурата. По този начин всеки компонент може да се развива самостоятелно.

Единственото условие на REST архитектурата, което не е задължително е "Код по поискване". Всяко приложение (услуга), изпълняващо на гореописаните условия, може да се нарече "RESTful". Ако нарушава дори едно от условията, то не може да бъде считано за "RESTful".

Всяка разпространена хипермедийна система, съответстваща на архитектурния стил на "REST" притежава нужната производителност, мащабируемост, опростеност, гъвкавост, видимост, портативност и надеждност.

RESTful API

RESTful уеб API (също наричано RESTful уеб service) е уеб приложение,което използва принципите на HTTP и REST. Представлява колекция от ресурси със четири дефинирани аспектa:

Основният "URL" за уеб приложенията като http://example.com/resources/
Internet media типът на данните поддържани от уеб приложенията. Това най-честo е JSON, но може да бъде всеки друг валиден Интернет медиен тип, като се има предвид, че е валиден хипертекст стандарт.
Операции поддържани от уеб приложението използвайки HTTP методи (примерно: GET, PUT, POST, или DELETE).
Приложенията трябва да се задвижват от хипертекст.

Таблицата показва как HTTP методите обикновено се използват, за да се създаде уеб приложение.

RESTful уеб API HTTP методи
Ресурс	GET	PUT	POST	DELETE
Collection URI, като `http://example.com/resources`	Подрежда URL адресите и някои други детайли на членовете на колекцията.	Заменя цялата колекция с друга колекция.	Създава нов вход в колекцията. URL адресът на новия вход е определен автоматично и обикновено се връща от операцията.	Трие цялата колекция.
Element URI, като `http://example.com/resources/item17`	Връща представяне на адресирания член на колекцията, изразена във подходящ Интернет медия тип.	Заменя адресирания член на колекцията или ако не съществува го създава.	Обикновено не се използва.	Трие адресираният член на колекцията. Третира адресираният член като собствена колекция и прави нов вход за нея.

Методите PUT и DELETE са idempotent methods. Методът GET е безопасен метод, което означава, че извикването му не причинява странични ефекти. За разлика от SOAP - базираните уеб услуги, няма "официален" стандарт за RESTful уеб API. Това е така, защото REST е архитектурен стил за разлика от SOAP, който е протокол. Въпреки, че REST не е стандарт, REST имплементация като Уеб може да използва стандарти като HTTP, URL, XML etc.

Интерфейс

Единният интерфейс на REST се счита за основа на дизайна на всяка REST услуга.

Идентификация на ресурсите

Отделните ресурси се разпознават по заявките (например използвайки [URIs] в уеб-базирани REST системи). Самите ресурсите са отделни от изображението, което се изпраща на клиента. Например сървърът вместо да изпраща цялата база данни, изпраща HTML, XML или JSON, които представляват някакви записи в нея.

Управление на ресурс чрез изображение

Имайки изображение на ресурса, клиента има достатъчно информация,с която може да променя или трие ресурсите от сървъра, в случай че има разрешението да го направи.

Самоописващи съобщения

Всяко съобщение включва информация, която описва как да се обработи съобщението.

HATEOAS (Hypermedia as the Engine of Application State)

[HATEOAS] е ограничението, което отличава архитектурата на REST приложението от повечето архитектури на мрежови приложения. При нея клиента „общува“ с приложението изцяло чрез [hypermedia], получена динамично от сървърa.

Примери за Rest

Rest може да бъде намерен в много места на публичният уеб.

Atom Publishing Protocol за публикуване към блогове се смята за канонически RESTful протокол.
Sun Microsystems' Cloud API е добър пример за документация, тип медия.
Инициативата Open Services for Lifecycle Collaboration (OSLC)създава RESTful подход към обединяване на софтуерни продукти.
CouchDB е документно ориентирана база данни написана в Erlang, която предоставя RESTful JSON API, който може да достъпен от всяка среда, която поддържа HTTP молби.
MySQL Cluster база данни достижима през прост REST/JSON интерфейс като Apache модул.
Canonical REST Entity Service на Microsoft.
Nuxeo, open sourse документ мениджър, създава Content Automation интерфейс чрез REST API.
Restful Objects, публична спецификация за общ RESTful API за всеки домейн обект модел.
Sones GraphDB е графа - ориентирана база данни написана на C#, която предоставя RESTful интерфейс.
Поддръжката на Google Fusion Tables включва RESTful API

Вижте също

RSDL (RESTful Service Description Language)
Clean URLs
Create, read, update and delete (CRUD)
Resource-oriented architecture (ROA)
Service-oriented architecture (SOA)
Resource-oriented computing (ROC)
HTTP
уеб приложение
World Wide Web Consortium

Източници

http://rest.elkstein.org/2008/02/what-is-rest.html http://www.techopedia.com/definition/1312/representational-state-transfer-rest

@@ Ред 5: / Ред 5: @@
 == История ==
 Архитектурният стил на "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) Репрезентация] на ресурс обикновено е документ, който намира сегашното възнамерявано състояние на ресурса.
+REST - стилът обикновено се състои от [http://en.wikipedia.org/wiki/Client_(computing) клиенти] и [http://en.wikipedia.org/wiki/Server_(computing) сървъри]. Клиентите инициират заявки към сървърите; сървърите преработват заявките и връщат подходящи отговори. Заявките и отговорите са създадени през прехвърляне на образа на ресурси. [http://en.wikipedia.org/wiki/Web_resource Ресурсът] може да бъде всякаква ясна и смислена концепция, която може да бъде адресирана. [[:en:Representation_(systemics)|Представяне]] (анг. representation) на ресурс обикновено е документ, който намира сегашното възнамерявано състояние на ресурса.
-Клиентът започва да изпраща заявки, когато е готов да направи преходът към ново състояние. Докато една или повече заявки са неизпълнени за клиента се смята, че е в преход. Репрезентацията на всяко приложение се състои от линкове, които могат да бъдат използвани следващия път, когато клиентът избере да направи нови официални промени.
+Клиентът започва да изпраща заявки, когато е готов да направи преходът към ново състояние. Докато една или повече заявки са неизпълнени за клиента се смята, че е в преход. Представянето на всяко приложение се състои от линкове, които могат да бъдат използвани следващия път, когато клиентът избере да направи нови официални промени.
 == Условия ==
@@ Ред 47: / Ред 47: @@
 |-
 ! Element URI, като <code><nowiki>http://example.com/resources/item17</nowiki></code>
-| '''Връща''' репрезентация на адресирания член на колекцията, изразена във подходящ Интернет медия тип.
+| '''Връща''' представяне на адресирания член на колекцията, изразена във подходящ Интернет медия тип.
 | '''Заменя''' адресирания член на колекцията или ако не съществува го '''създава'''.
 |Обикновено не се използва.