대기업이 REST API를 디자인하는 것을 본 모든 방법을 기반으로 REST를 올바르게 사용하는 방법에 대해 약간 혼란스러워하는 것은 이해할 만합니다.
REST가 자원 콜렉션 시스템이라는 점이 맞습니다. 그것은 대표 국가 이전을 의미합니다. 당신이 나에게 묻는다면 큰 정의가 아닙니다. 그러나 주요 개념은 4 개의 HTTP 동사이며 상태 비 저장입니다.
주의해야 할 중요한 부분은 REST가있는 4 개의 동사 만 있다는 것입니다. 이들은 GET, POST, PUT 및 DELETE입니다. 귀하의 resend예는 REST에 새로운 동사를 추가하는 것입니다. 이것은 붉은 깃발이어야합니다.
질문 1
REST API 호출자는 PUT콜렉션에서 수행을 수행하면 이메일이 생성됨 을 알 필요가 없다는 것을 인식해야합니다 . 그것은 나에게 새는 냄새가 난다. 그들이 알 수있는 것은 PUT나중에 수행 할 수있는 추가 작업 을 수행 할 수 있다는 것입니다 . 그들은 GET최근에 생성 된 리소스 를 수행함으로써 이것을 알 것 입니다. 그러면 GET리소스와 Task연결된 모든 리소스 ID 가 반환 됩니다. 그런 다음 나중에 해당 작업을 쿼리하여 상태를 확인하고 새 작업을 제출할 수도 Task있습니다.
몇 가지 옵션이 있습니다.
REST-태스크 자원 기반 접근법
tasks시스템에 특정 작업을 제출하여 작업을 수행 할 수 있는 리소스를 만듭니다 . 그런 다음 반환 된 GET작업을 기반으로 작업 ID의 상태를 확인할 수 있습니다.
또는 SOAP over HTTP웹 서비스를 혼합 하여 아키텍처에 RPC를 추가 할 수 있습니다.
특정 리소스에 대한 모든 작업 쿼리
GET http://server/api/myCollection/123/tasks
{ "tasks" :
[ { "22333" : "http://server/api/tasks/223333" } ]
}
작업 리소스 예
PUT http://server/api/tasks
{
"type" : "send-email" ,
"parameters" :
{
"collection-type" : "foo" ,
"collection-id" : "123"
}
}
==> 작업 ID를 반환
223334
GET http://server/api/tasks/223334
{
"status" : "complete" ,
"date" : "whenever"
}
REST- POST를 사용하여 조치 트리거
언제든지 POST리소스에 추가 데이터를 추가 할 수 있습니다 . 제 생각에는 이것이 REST 정신을 위반하지만 여전히 준수 할 것입니다.
다음과 비슷한 POST를 수행 할 수 있습니다.
POST http://server/api/collection/123
{ "action" : "send-email" }
추가 데이터로 콜렉션에서 자원 123을 업데이트합니다. 추가 데이터는 본질적으로 백엔드에게 해당 리소스에 대한 전자 메일을 보내도록 지시하는 작업입니다.
내가 가진 문제 GET는 리소스 에이 업데이트 된 데이터를 반환 한다는 것입니다. 그러나 이것은 요구 사항을 해결하고 여전히 RESTful입니다.
SOAP-REST에서 얻은 자원을 승인하는 웹 서비스
REST API에서 이전 자원 ID를 기반으로 이메일을 보낼 수있는 새 WebService를 작성하십시오. 원래 질문은 REST에 관한 것이기 때문에 SOAP에 대해 자세히 설명하지 않겠습니다.이 두 개념 / 기술은 Apples 및 Oranges와 비교할 수 없습니다 .
질문 2
여기에는 몇 가지 옵션이 있습니다.
REST API를 게시하는 많은 대기업 search이 실제로 리소스를 반환하기 위해 쿼리 매개 변수를 전달하는 방법 인 컬렉션을 노출시키는 것으로 보입니다 .
GET http://server/api/search?q="type = myCollection & someField >= someval"
다음과 같은 정규화 된 REST 자원 콜렉션을 리턴합니다.
{
"results" :
{ [
"location" : "http://server/api/myCollection/1",
"location" : "http://server/api/myCollection/9",
"location" : "http://server/api/myCollection/56"
]
}
}
또는 MVEL 과 같은 것을 쿼리 매개 변수로 허용 할 수 있습니다 .
질문 3
쿼리 매개 변수를 사용하여 다른 리소스를 백업하고 쿼리하는 것보다 하위 수준을 선호합니다. 나는 어떤 식 으로든 규칙이 있다고 생각하지 않습니다. 두 가지 방법을 모두 구현하고 발신자가 시스템에 처음 들어간 방법에 따라 더 적합한 방법을 결정할 수 있습니다.
노트
나는 다른 사람들의 가독성 의견에 동의하지 않습니다. 일부 사람들은 REST가 여전히 인간의 소비가 아니라고 생각할 수도 있습니다. 기계 소 비용입니다. 내 트윗을 보려면 Twitter의 일반 웹 사이트를 사용합니다. API로 REST GET을 수행하지 않습니다. 트윗으로 프로그래밍 방식으로 무언가를하고 싶다면 REST API를 사용합니다. 예, API는 이해할 수 있어야하지만 gte그렇게 나쁘지는 않습니다. 직관적이지 않습니다.
REST의 또 다른 주요 사항은 API의 특정 시점에서 시작하여 미리 다른 리소스의 정확한 URL을 알지 않고도 다른 모든 관련 리소스로 이동할 수 있어야한다는 것입니다. GETREST 에서 동사 의 결과는 참조하는 자원의 전체 REST URL을 리턴해야합니다. 따라서 Person개체 의 ID를 반환하는 쿼리 대신 과 같은 정규화 된 URL을 반환합니다 http://server/api/people/13. 그러면 URL이 변경된 경우에도 항상 프로그래밍 방식으로 결과를 탐색 할 수 있습니다.
의견에 대한 답변
실제로는 자원을 생성, 읽기, 업데이트 또는 삭제 (CRUD)하지 않는 일이 실제로 발생합니다.
자원에 대한 추가 조치를 수행 할 수 있습니다. 일반적인 관계형 데이터베이스는 저장 프로 시저 개념을 지원합니다. 이들은 일련의 데이터에서 실행될 수있는 추가 명령입니다. REST에는 본질적으로 해당 개념이 없습니다. 그리고 그럴 이유가 없습니다. 이러한 유형의 작업은 RPC 또는 SOAP 웹 서비스에 적합합니다.
이것이 REST API에서 볼 수있는 일반적인 문제입니다. 개발자는 REST를 둘러싼 개념적 제한을 좋아하지 않기 때문에 원하는대로 수행 할 수 있습니다. 그래도 RESTful 서비스가 아닙니다. 본질적으로 이러한 URL GET은 의사 -REST와 유사한 서블릿에 대한 호출이됩니다.
몇 가지 옵션이 있습니다.
- 작업 리소스 생성
POST자원에 추가 데이터를 지원 하여 조치 수행- SOAP 웹 서비스를 통해 추가 명령을 추가하십시오.
쿼리 매개 변수를 사용하여 전자 메일을 다시 보내는 데 사용할 HTTP 동사는 무엇입니까?
GET-이메일을 다시 보내고 리소스 데이터를 반환합니까? 시스템이 해당 URL을 캐시하고 해당 자원의 고유 URL처럼 처리하면 어떻게됩니까? 그들이 URL을 칠 때마다 이메일을 다시 보냅니다.POST -실제로 새로운 데이터를 리소스로 보내지 않고 추가 쿼리 매개 변수 만 사용했습니다.
주어진 모든 요구 사항에 따라 POST 데이터 POST를 사용하여 리소스를 수행 action field하면 문제가 해결됩니다.