[http] RESTful 프로그래밍이란 정확히 무엇입니까?

RESTful 프로그래밍이란 정확히 무엇입니까?



답변

건축 양식 이라고 REST (Representational State Transfer)는 이되면서 그 웹 애플리케이션이 HTTP를 사용한다 옹호 원래 구상 . 조회는 GET요청 을 사용해야 합니다. PUT, POSTDELETE요청각각 돌연변이, 생성 및 결실에 사용되어야합니다 .

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 요청은 dem 등원 이어야합니다 . 즉, 요청을 두 번 발행하는 것이 요청을 한 번 발행하는 것과 다르지 않아야합니다. 그것이 요청을 캐시 가능하게 만드는 것입니다. “장바구니에 추가”요청은 dem 등성이 아닙니다. 두 번 발행하면 두 부의 품목 사본이 카트에 추가됩니다. 이 상황에서는 POST 요청이 분명히 적합합니다. 따라서 RESTful 웹 애플리케이션 조차도 POST 요청을 공유해야합니다.

이것은 David M. Geary의 Core JavaServer faces 책 에서 발췌 한 것 입니다.


답변

REST 는 웹의 기본 아키텍처 원칙입니다. 웹의 놀라운 점은 클라이언트 (브라우저)와 서버가 클라이언트가 서버와 서버가 호스팅하는 리소스에 대해 미리 알 필요없이 복잡한 방식으로 상호 작용할 수 있다는 사실입니다. 주요 제약 조건은 서버와 클라이언트가 사용되는 미디어에 동의해야한다는 것 입니다. 웹의 경우 HTML 입니다.

REST 원칙을 준수하는 API 는 클라이언트가 API 구조에 대해 아무것도 알 필요가 없습니다. 오히려 서버는 클라이언트가 서비스와 상호 작용하는 데 필요한 정보를 제공해야합니다. HTML 형태는 그 예이다 : 서버 자원 및 필수 필드의 위치를 지정한다. 브라우저는 정보를 제출할 위치를 미리 알지 못하며 제출할 정보를 미리 알지 못합니다. 두 형태의 정보는 전적으로 서버에 의해 제공됩니다. (이 원칙을 HATEOAS : 응용 프로그램 엔진 상태의 하이퍼 미디어 라고 합니다.)

그렇다면 이것이 HTTP 에 어떻게 적용 되며 실제로 어떻게 구현할 수 있습니까? HTTP는 동사와 리소스를 중심으로합니다. 주류 사용에 사용되는 두 동사는 GETand POST입니다. 그러나, HTTP 표준은 다음과 같은 몇 가지 다른 정의 PUTDELETE. 그런 다음 서버에서 제공 한 지시 사항에 따라이 동사가 자원에 적용됩니다.

예를 들어 웹 서비스에서 관리하는 사용자 데이터베이스가 있다고 가정 해 봅시다. 우리의 서비스는 우리가 MIME 형식을 지정하는 JSON을 기반으로 사용자 정의 하이퍼 미디어를 사용 application/json+userdb(도있을 수 있습니다 application/xml+userdbapplication/whatever+userdb– 여러 미디어 유형이 지원 될 수있다). 클라이언트와 서버는이 형식을 이해하도록 프로그래밍되었지만 서로에 대해 아무것도 모릅니다. Roy Fielding이 지적한 바와 같이 :

REST API는 리소스를 표현하고 애플리케이션 상태를 구동하는 데 사용되는 미디어 유형을 정의하거나 기존 표준 미디어 유형에 대한 확장 관계 이름 및 / 또는 하이퍼 텍스트 가능 마크 업을 정의하는 데 거의 모든 설명적인 노력을 기울여야합니다.

기본 자원에 대한 요청은 /다음과 같은 것을 리턴 할 수 있습니다.

의뢰

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"
        }
    ]
}

이 답변에서 많은 것을 알 수 있습니다. 예를 들어, 우리는 지금 우리가 새로운 사용자를 생성 할 수 있습니다 알고 POST에 보내고 /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가 일반적으로 구현 된 방식과 더 관련이있었습니다. 처음에는 이것이 진정한 의미가 아니라 이것을 썼습니다. 나는 실제 의미를 더 잘 표현하기 위해 답을 수정했습니다.)


답변

RESTful 프로그래밍은 다음과 같습니다.

  • 영구 식별자로 식별되는 자원 : 요즘 URI는 유비쿼터스의 식별자 선택입니다.
  • 자원은 동사의 공통 사용하여 조작되는 : HTTP를 방법은 일반적으로 볼 경우입니다 – 오래된 Create, Retrieve, Update, Delete된다 POST, GET, PUT,와 DELETE. 그러나 REST는 HTTP로 제한되지 않으며 현재 가장 일반적으로 사용되는 전송입니다.
  • 자원에 대해 검색된 실제 표현은 식별자가 아닌 요청에 따라 다릅니다. Accept 헤더를 사용하여 XML, HTTP 또는 자원을 나타내는 Java 오브젝트를 원하는지 여부를 제어하십시오.
  • 객체에서 상태를 유지하고 표현에서 상태를 나타냄
  • 자원 표현에서 자원들 간의 관계를 나타내는 것 : 객체들 사이의 링크는 표현에 직접 포함된다
  • 자원 표현은 표현을 사용하는 방법과 일관된 방식으로 표현을 버리고 다시 가져와야하는 상황을 설명합니다. HTTP 캐시 제어 헤더 사용

마지막 것은 아마도 REST의 결과 및 전반적인 효과면에서 가장 중요합니다. 전반적으로, RESTful 토론의 대부분은 HTTP와 브라우저에서의 사용법 및 그렇지 않은 것에 중점을 둔 것으로 보입니다. 필자는 R. Fielding이 HTTP로 이끄는 아키텍처와 결정을 설명 할 때이 용어를 만들었다는 것을 이해합니다. 그의 논문은 HTTP보다는 리소스의 아키텍처 및 캐시 가능성에 관한 것입니다.

RESTful 아키텍처가 무엇이고 왜 작동하는지에 정말로 관심이 있다면, 그의 논문 을 몇 번 읽고 5 장뿐만 아니라 전체 내용을 읽으십시오 ! 다음으로 DNS가 작동하는 이유를 살펴보십시오 . DNS의 계층 적 구성 및 조회 작동 방식에 대해 읽으십시오. 그런 다음 DNS 캐싱 작동 방식을 읽고 고려하십시오. 마지막으로 HTTP 사양 ( 특히 RFC2616RFC3040 )을 읽고 캐싱이 작동하는 방식과 이유를 고려하십시오. 결국 클릭 만하면됩니다. 마지막 계시는 DNS와 HTTP의 유사성을 보았을 때였습니다. 그런 다음 SOA 및 메시지 전달 인터페이스가 확장 가능한 이유를 이해하면 클릭이 시작됩니다.

RESTful 및 Shared Nothing 아키텍처 의 아키텍처 중요성 및 성능 관련 사항을 이해하는 가장 중요한 트릭 은 기술 및 구현 세부 사항에 얽매이지 않는 것입니다. 자원을 소유 한 사람, 자원을 생성 / 유지 관리하는 담당자 등에 집중하십시오. 그런 다음 표현, 프로토콜 및 기술에 대해 생각하십시오.


답변

이것은 다음과 같습니다.

세 가지 속성을 가진 사용자를 만듭니다.

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

서버는 다음과 같이 응답합니다.

200 OK
Location: /user/123

나중에 사용자 정보를 검색 할 수 있습니다.

GET /user/123

서버는 다음과 같이 응답합니다.

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

레코드를 수정하려면 ( lnameage변경되지 않은 상태로 유지) :

PATCH /user/123
fname=Johnny

레코드를 업데이트하려면 (결과적 lnameageNULL이됩니다)

PUT /user/123
fname=Johnny


답변

REST에 대한 훌륭한 책 은 실습 에서 REST입니다 .

읽기는 REST (Representational State Transfer) 여야 하고 REST API는 하이퍼 텍스트 중심이어야합니다.

RESTful 서비스가 무엇인지에 대한 설명 은 Martin Fowlers 기사 Richardson Maturity Model (RMM)을 참조하십시오 .

리차드슨 성숙 모형

RESTful 상태가 되려면 서비스 상태 엔진으로서 Hypermedia 를 이행해야합니다 . (HATEOAS은) , 즉, 그것은는 RMM에서 레벨 3에 도달 할 필요가 기사 읽기 세부 사항 또는 대한 qcon 대화에서 슬라이드를 .

HATEOAS 제한 조건은 응용 프로그램 엔진의 엔진으로서 Hypermedia의 약어입니다. 이 원칙은 REST와 대부분의 다른 형태의 클라이언트 서버 시스템을 구분하는 주요 차이점입니다.

RESTful 애플리케이션의 클라이언트는 단일 고정 URL 만 알고 있으면 액세스 할 수 있습니다. 해당 URL에서 반환되는 리소스 표현에 포함 된 하이퍼 미디어 링크에서 향후 모든 작업을 동적으로 검색 할 수 있어야합니다. 표준화 된 미디어 유형은 RESTful API를 사용하는 모든 클라이언트에 의해 이해 될 것으로 예상됩니다. (무료 백과 사전, 위키피디아에서)

웹 프레임 워크 용 REST Litmus 테스트는 웹 프레임 워크 에 대한 유사한 성숙도 테스트입니다.

순수한 REST에 접근하기 : HATEOAS를 사랑하는 법 은 훌륭한 링크 모음입니다.

퍼블릭 클라우드 용 REST 대 SOAP 는 현재 레벨의 REST 사용량에 대해 설명합니다.

REST 및 버전 관리 는 수정 가능성을 통해 확장 성, 버전 관리, 진 화성 등에 대해 설명합니다.


답변

REST 란 무엇입니까?

REST는 Representational State Transfer를 나타냅니다. (때로는 “ReST”로 표기됩니다.) 상태 비 저장 클라이언트 서버 캐시 가능 통신 프로토콜을 사용하며 거의 모든 경우 HTTP 프로토콜이 사용됩니다.

REST는 네트워크 애플리케이션을 설계하기위한 아키텍처 스타일입니다. 아이디어는 CORBA, RPC 또는 SOAP와 같은 복잡한 메커니즘을 사용하여 시스템간에 연결하는 대신 간단한 HTTP를 사용하여 시스템간에 호출하는 것입니다.

여러 가지면에서 HTTP 기반의 월드 와이드 웹 자체는 REST 기반 아키텍처로 볼 수 있습니다. RESTful 애플리케이션은 HTTP 요청을 사용하여 데이터 게시 (생성 및 / 또는 업데이트), 데이터 읽기 (예 : 쿼리 작성) 및 데이터 삭제를 수행합니다. 따라서 REST는 4 개의 CRUD (작성 / 읽기 / 업데이트 / 삭제) 오퍼레이션 모두에 HTTP를 사용합니다.

REST는 RPC (Remote Procedure Calls) 및 웹 서비스 (SOAP, WSDL 등)와 같은 메커니즘에 대한 간단한 대안입니다. 나중에 REST가 얼마나 간단한 지 살펴 보겠습니다.

단순함에도 불구하고 REST는 모든 기능을 갖추고 있습니다. RESTful 아키텍처로는 수행 할 수없는 웹 서비스에서 기본적으로 수행 할 수있는 작업이 없습니다. REST는 “표준”이 아닙니다. 예를 들어 REST에 대한 W3C 권장 사항은 없습니다. REST 프로그래밍 프레임 워크가 있지만 REST 작업은 매우 간단하여 Perl, Java 또는 C #과 같은 언어의 표준 라이브러리 기능을 사용하여 “자신의 롤”을 수행 할 수 있습니다.

내가 쉬는 것의 단순한 진정한 의미를 찾으려고 할 때 내가 찾은 최고의 참고 문헌 중 하나.

http://rest.elkstein.org/


답변

REST는 다양한 HTTP 메소드 (주로 GET / PUT / DELETE)를 사용하여 데이터를 조작합니다.

메소드를 삭제하기 위해 특정 URL을 사용하는 대신 (예 /user/123/delete🙂 /user/[id]URL에 DELETE 요청을 보내고 , 사용자를 편집하고, GET 요청을 보낸 사용자에 대한 정보를 검색합니다./user/[id]

예를 들어, 다음 중 일부와 유사한 URL 세트가 있습니다.

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

HTTP “동사”를 사용하고 있습니다.

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