REST 는 웹의 기본 아키텍처 원칙입니다. 웹의 놀라운 점은 클라이언트 (브라우저)와 서버가 클라이언트가 서버와 서버가 호스팅하는 리소스에 대해 미리 알 필요없이 복잡한 방식으로 상호 작용할 수 있다는 사실입니다. 주요 제약 조건은 서버와 클라이언트가 사용되는 미디어에 동의해야한다는 것 입니다. 웹의 경우 HTML 입니다.
REST 원칙을 준수하는 API 는 클라이언트가 API 구조에 대해 아무것도 알 필요가 없습니다. 오히려 서버는 클라이언트가 서비스와 상호 작용하는 데 필요한 정보를 제공해야합니다. HTML 형태는 그 예이다 : 서버 자원 및 필수 필드의 위치를 지정한다. 브라우저는 정보를 제출할 위치를 미리 알지 못하며 제출할 정보를 미리 알지 못합니다. 두 형태의 정보는 전적으로 서버에 의해 제공됩니다. (이 원칙을 HATEOAS : 응용 프로그램 엔진 상태의 하이퍼 미디어 라고 합니다.)
그렇다면 이것이 HTTP 에 어떻게 적용 되며 실제로 어떻게 구현할 수 있습니까? HTTP는 동사와 리소스를 중심으로합니다. 주류 사용에 사용되는 두 동사는 GETand POST입니다. 그러나, HTTP 표준은 다음과 같은 몇 가지 다른 정의 PUT와 DELETE. 그런 다음 서버에서 제공 한 지시 사항에 따라이 동사가 자원에 적용됩니다.
예를 들어 웹 서비스에서 관리하는 사용자 데이터베이스가 있다고 가정 해 봅시다. 우리의 서비스는 우리가 MIME 형식을 지정하는 JSON을 기반으로 사용자 정의 하이퍼 미디어를 사용 application/json+userdb(도있을 수 있습니다 application/xml+userdb및 application/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가 일반적으로 구현 된 방식과 더 관련이있었습니다. 처음에는 이것이 진정한 의미가 아니라 이것을 썼습니다. 나는 실제 의미를 더 잘 표현하기 위해 답을 수정했습니다.)
