Вопрос: Что такое программирование RESTful?


Что такое программирование RESTful?


3581


источник


Ответы:


архитектурный стиль называется REST (Передача репрезентативного состояния) утверждает, что веб-приложения должны использовать HTTP так, как это было первоначально предполагалось , Поиск должен использовать GETЗапросы. PUT, POST, а также DELETEЗапросы следует использовать для мутации, создания и удаления соответственно ,

Сторонники REST предпочитают URL-адреса, такие как

http://myserver.com/catalog/item/1729

но архитектура REST не требует этих «хороших URL-адресов». Запрос GET с параметром

http://myserver.com/catalog?item=1729

каждый бит как RESTful.

Имейте в виду, что GET-запросы никогда не должны использоваться для обновления информации. Например, запрос GET для добавления элемента в корзину

http://myserver.com/addToCart?cart=314159&item=1729

было бы неуместным. Запросы GET должны быть идемпотент , То есть, выдача запроса дважды не должна отличаться от его выдачи один раз. Это делает запросы кэшируемыми. Запрос «добавить в корзину» не является идемпотентным - выпуск его дважды добавляет две копии товара в корзину. В этом контексте явно подходит запрос POST. Таким образом, даже Веб-приложение RESTful нуждается в его части запросов POST.

Это взято из превосходной книги Основные грани JavaServer книга Дэвида М. Гири.


515



ОТДЫХ является основным архитектурным принципом Интернета. Удивительной вещью в Интернете является тот факт, что клиенты (браузеры) и серверы могут взаимодействовать сложными способами без того, чтобы клиент заранее ничего не знал о сервере и ресурсах, которые он размещает. Ключевым ограничением является то, что сервер и клиент должны СМИ , который в случае сети HTML ,

API, который придерживается принципов ОТДЫХ не требует от клиента знать что-либо о структуре API. Скорее, сервер должен предоставлять любую информацию, которую клиент должен взаимодействовать с сервисом. Форма HTML пример этого: сервер определяет местоположение ресурса и необходимые поля. Браузер не знает заранее, куда подавать информацию, и заранее не знает, какую информацию отправить. Обе формы информации полностью предоставляются сервером. (Этот принцип называется HATEOAS : Гипермедиа как двигатель состояния приложения .)

Итак, как это относится к HTTP , и как это можно реализовать на практике? HTTP ориентирован на глаголы и ресурсы. Два глагола в основном использовании GET и POST, которые, как я думаю, все узнают. Тем не менее, стандарт HTTP определяет несколько других, таких как PUT и DELETE. Эти глаголы затем применяются к ресурсам в соответствии с инструкциями, предоставленными сервером.

Например, представим себе, что у нас есть пользовательская база данных, управляемая веб-службой. Наша служба использует настраиваемую гипермедиа на основе JSON, для которой мы присваиваем тип mimetype Применение / JSON + userdb (Также может быть Приложение / XML + userdb а также Приложение / все + userdb - многие типы носителей могут поддерживаться). Клиент и сервер были запрограммированы так, чтобы понимать этот формат, но они ничего не знают друг о друге. В виде Рой Филдинг указывает на то:

API REST должен тратить почти все свои описательные   определение типов (-ов) носителей, используемых для представления ресурсов и вождения   состояния приложения или определения имен расширенных отношений и / или   гипертекстовая разметка для существующих стандартных типов носителей.

Запрос базового ресурса /может вернуть что-то вроде этого:

Запрос

GET /
Accept: application/json+userdb

отклик

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Из описания наших СМИ мы знаем, что мы можем найти информацию о связанных ресурсах из разделов, называемых «ссылками». Это называется Гипермедиа , В этом случае мы можем сказать из такого раздела, что мы можем найти список пользователей, сделав еще один запрос для /user:

Запрос

GET /user
Accept: application/json+userdb

отклик

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Мы можем многое сказать из этого ответа. Например, теперь мы знаем, что мы можем создать нового пользователя с помощью POSTing /user:

Запрос

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

отклик

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Мы также знаем, что мы можем изменить существующие данные:

Запрос

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

отклик

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Обратите внимание, что мы используем разные HTTP-глаголы (GET, PUT, POST, DELETE и т. Д.) Для управления этими ресурсами и что единственное знание, которое мы предполагаем на стороне клиента, - это наше определение медиа.

Дальнейшее чтение:

(Этот ответ был предметом большого количества критики за то, что он пропустил этот пункт. По большей части это была справедливая критика. То, что я изначально описал, было в большей степени согласуется с тем, как REST обычно осуществлялся несколько лет назад, когда я сначала написал это, а не его истинный смысл. Я пересмотрел ответ, чтобы лучше представить реальный смысл.)


2772



Программирование RESTful:

  • ресурсы идентифицируются постоянным идентификатором: URI являются вездесущим выбором идентификатора в эти дни
  • ресурсы управляются с помощью общего набора глаголов: HTTP-методы - это часто встречающийся случай - почтенный Create, Retrieve, Update, Deleteстановится POST, GET, PUT, а также DELETE, Но REST не ограничивается только HTTP, это просто самый распространенный транспорт прямо сейчас.
  • фактическое представление, полученное для ресурса, зависит от запроса, а не от идентификатора: используйте заголовки Accept, чтобы контролировать, хотите ли вы XML, HTTP или даже объект Java, представляющий ресурс
  • сохранение состояния в объекте и представление состояния в представлении
  • представляющие отношения между ресурсами в представлении ресурса: связи между объектами встроены непосредственно в представление
  • представления ресурсов описывают, как можно использовать представление и при каких обстоятельствах его следует отбрасывать / повторять последовательно: использование заголовков HTTP Cache-Control

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

Если вас действительно интересует архитектура RESTful и почему она работает, прочитайте его тезис несколько раз и Все это не только глава 5! Следующий взгляд почему DNS работает , Читайте об иерархической организации DNS и о том, как работают рефералы. Затем прочитайте и рассмотрите, как работает кеширование DNS. Наконец, прочитайте спецификации HTTP ( RFC2616 а также RFC3040 в частности) и рассмотрим, как и почему кеширование работает так, как оно делает. В конце концов, он просто щелкнет. Последнее откровение для меня было, когда я увидел сходство между DNS и HTTP. После этого становится понятно, почему масштабируемые интерфейсы SOA и Message Passing Interfaces становятся доступными.

Я думаю, что самый важный трюк для понимания архитектурной важности и эффективности работы RESTful и Ничего общего архитектуры, чтобы избежать повесить на технологии и детали реализации. Сосредоточьтесь на том, кто владеет ресурсами, кто отвечает за их создание / поддержание и т. Д. Тогда подумайте о представлениях, протоколах и технологиях.


496



This is what it might look like.

Create a user with three properties:

POST /user
fname=John&lname=Doe&age=25

The server responds:

200 OK
Location: /user/123

In the future, you can then retrieve the user information:

GET /user/123

The server responds:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

To modify the record (lname and age will remain unchanged):

PATCH /user/123
fname=Johnny

To update the record (and consequently lname and age will be NULL):

PUT /user/123
fname=Johnny

391



A great book on REST is REST in Practice.

Must reads are Representational State Transfer (REST) and REST APIs must be hypertext-driven

See Martin Fowlers article the Richardson Maturity Model (RMM) for an explanation on what an RESTful service is.

Richardson Maturity Model

To be RESTful a Service needs to fulfill the Hypermedia as the Engine of Application State. (HATEOAS), that is, it needs to reach level 3 in the RMM, read the article for details or the slides from the qcon talk.

The HATEOAS constraint is an acronym for Hypermedia as the Engine of Application State. This principle is the key differentiator between a REST and most other forms of client server system.

...

A client of a RESTful application need only know a single fixed URL to access it. All future actions should be discoverable dynamically from hypermedia links included in the representations of the resources that are returned from that URL. Standardized media types are also expected to be understood by any client that might use a RESTful API. (From Wikipedia, the free encyclopedia)

REST Litmus Test for Web Frameworks is a similar maturity test for web frameworks.

Approaching pure REST: Learning to love HATEOAS is a good collection of links.

REST versus SOAP for the Public Cloud discusses the current levels of REST usage.

REST and versioning discusses Extensibility, Versioning, Evolvability, etc. through Modifiability


170



What is REST?

REST stands for Representational State Transfer. (It is sometimes spelled "ReST".) It relies on a stateless, client-server, cacheable communications protocol -- and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture. RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

Despite being simple, REST is fully-featured; there's basically nothing you can do in Web Services that can't be done with a RESTful architecture. REST is not a "standard". There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often "roll your own" with standard library features in languages like Perl, Java, or C#.

One of the best reference I found when I try to find the simple real meaning of rest.

http://rest.elkstein.org/


128



REST is using the various HTTP methods (mainly GET/PUT/DELETE) to manipulate data.

Rather than using a specific URL to delete a method (say, /user/123/delete), you would send a DELETE request to the /user/[id] URL, to edit a user, to retrieve info on a user you send a GET request to /user/[id]

For example, instead a set of URLs which might look like some of the following..

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

You use the HTTP "verbs" and have..

GET /user/2
DELETE /user/2
PUT /user

85



It's programming where the architecture of your system fits the REST style laid out by Roy Fielding in his thesis. Since this is the architectural style that describes the web (more or less), lots of people are interested in it.

Bonus answer: No. Unless you're studying software architecture as an academic or designing web services, there's really no reason to have heard the term.


63



I would say RESTful programming would be about creating systems (API) that follow the REST architectural style.

I found this fantastic, short, and easy to understand tutorial about REST by Dr. M. Elkstein and quoting the essential part that would answer your question for the most part:

Learn REST: A Tutorial

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

  • In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.

RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

I don't think you should feel stupid for not hearing about REST outside Stack Overflow..., I would be in the same situation!; answers to this other SO question on Why is REST getting big now could could ease some feelings.


43



I apologize if I'm not answering the question directly, but it's easier to understand all this with more detailed examples. Fielding is not easy to understand due to all the abstraction and terminology.

There's a fairly good example here:

Explaining REST and Hypertext: Spam-E the Spam Cleaning Robot

And even better, there's a clean explanation with simple examples here (the powerpoint is more comprehensive, but you can get most of it in the html version):

http://www.xfront.com/REST.ppt or http://www.xfront.com/REST.html

After reading the examples, I could see why Ken is saying that REST is hypertext-driven. I'm not actually sure that he's right though, because that /user/123 is a URI that points to a resource, and it's not clear to me that it's unRESTful just because the client knows about it "out-of-band."

That xfront document explains the difference between REST and SOAP, and this is really helpful too. When Fielding says, "That is RPC. It screams RPC.", it's clear that RPC is not RESTful, so it's useful to see the exact reasons for this. (SOAP is a type of RPC.)


43



What is REST?

REST in official words, REST is an architectural style built on certain principles using the current “Web” fundamentals. There are 5 basic fundamentals of web which are leveraged to create REST services.

  • Principle 1: Everything is a Resource In the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs), typically links on the Web.
  • Principle 2: Every Resource is Identified by a Unique Identifier (URI)
  • Principle 3: Use Simple and Uniform Interfaces
  • Principle 4: Communication is Done by Representation
  • Principle 5: Be Stateless

36



I see a bunch of answers that say putting everything about user 123 at resource "/user/123" is RESTful.

Roy Fielding, who coined the term, says REST APIs must be hypertext-driven. In particular, "A REST API must not define fixed resource names or hierarchies".

So if your "/user/123" path is hardcoded on the client, it's not really RESTful. A good use of HTTP, maybe, maybe not. But not RESTful. It has to come from hypertext.


32