REST URI에서 조치 (동사) 표시

고객 문서를 인쇄 할 작업이 있습니다. add, update, delete와 같은 다른 표준 작업도 수행해야합니다. 그래서, 나는 다음을 가지고있다 :

• 새 고객 작성 :
  URI = / customer / {id}, type = POST, Methodname = CreateCustomer ()
• 업데이트 :
  URI : / customer / {id}, type = PUT, method = UpdateCstomer ()
• 고객 삭제 :
  URI = / customer / {id}에 유형 = DELETE, 메소드 이름 = DeleteCustomer ()를 입력하십시오.
• 보기 :
  URI : / customer / {id}, 유형 = GET, 메소드 = GetCustomer ()

이제 해당 고객의 문서를 인쇄해야하는 경우 인쇄 기능이 필요합니다. 내 URI는 다음과 같습니다. / customer / {id}, type = POST, method = PrintCustomer (). 그러나 CreateCustomer에 해당 URI 및 POST 유형을 사용했습니다. URI가 / customer / Print / {id}, type = POST, method = PrintCustomer ()와 같이 표시되기를 원했습니다.

그러나 URI에 "Print"동사를 사용할 수 없습니다. 가장 좋은 방법은 무엇입니까? URI로 / customer / document / {id}를 생각했지만 같은 문제가 발생합니다. "문서"에 대한 CRUD 작업이 있습니다. 다시, 나는 "인쇄"에 사용했던 것을 다 썼다. 조언 부탁드립니다.

POST"생성"을 의미하는 것이 아니라 "프로세스"를 의미합니다. 기존 리소스에 적합한 요청을 게시하여 새 리소스를 만들 수 있습니다 (예 : /customers새 고객을 만들기 위해 게시 ). 그러나 POST깔끔한 CRUD 패러다임에 해당하지 않는 다른 모든 작업을 채우는 데 사용할 수도 있습니다 .

인쇄의 경우 리소스 자체로 인쇄하는 행위를 고려해야합니다. 시스템에 "인쇄 작업"을 작성하도록 요청하고 있습니다. 즉 prints/, 요청 된 모든 인쇄물의 컨테이너 역할을 하는 리소스를 가질 수 있습니다 . 인쇄하려는 POST리소스에 대한 모든 정보가 포함 된 문서를이 리소스에 인쇄하려는 경우 해당 리소스에 대한 링크로 인쇄하려는 리소스를 식별합니다.

JSON 문서는 다음과 같습니다.

{
   contents: ["http://site/customers/12345"],
   paper-size: "A4",
   duplex: "true"
}

분명히, 원하는 작업과 관련이 있도록이를 사용자 정의해야합니다. 중요한 것은 URL을 지정하여 인쇄 할 다른 리소스를 식별한다는 것입니다.

요청에 대한 응답으로 간단히 a 200 OK또는 a 를 반환하고 204 No-Content이를 잊어 버리는 과정으로 취급 할 수 있습니다. 그러나 향상 시키 201 Created려면 새로 만든 인쇄 작업의 URL을 반환 하여 지정할 수 있습니다 (예 :) /prints/12345.

그런 다음 사용자 GET는 자원에 대해 수행하여 인쇄 작업 상태 (보류 중, 진행 중 등)를 보거나을 발행하여 작업 취소를 요청할 수 있습니다 DELETE.

리소스 측면에서 문제를 다시 말하면 RESTful 디자인은 자연스럽게 나오고 즉시 고려하지 않은 방식으로 확장하고 향상시킬 수있는 기회를 제공해야합니다.

나는 전에 이것을했다. 문서를 인쇄하기 위해 pdf 버전의 리소스 만 반환합니다. 클라이언트는 Accept 헤더 application / pdf와 함께 리소스에 대한 GET 요청 만 보내면됩니다.

또한 인쇄 작업과 같은 임시 리소스에 대한 새 URI를 만들지 않아도됩니다. HTTP 헤더를 사용하는 것도 REST의 일부이며 URI를 깨끗하게 유지합니다.

현재 URI의 GET에 매개 변수를 추가하기 만하면됩니다.

여러 작업에 URI를 사용하는 것이 일반적입니다.

동일한 리소스이지만 다른 작업에 대해 이야기하는 경우이를 매개 변수로 정의합니다.

/ customer / {id}? print = true

그런 다음 GET 메소드를 정의 할 때 인쇄 매개 변수의 존재를 감지하고 다르게 처리합니다.

REST는 다음과 같은 방식으로 정의됩니다.

• POST-레코드, 자산 또는 리소스 생성
• PUT-업데이트, 레코드, 자산 또는 리소스
• 삭제-레코드, 자산 또는 자원 제거

반면에 GET은 일반적으로 리소스를 검색 할 수있는 다양한 형식이 많기 때문에 여러 가지 방법으로 사용됩니다. 이것이 GET 요청이 쿼리 문자열로 표시되는 이유이기도합니다. 데이터베이스 리소스로 작업하는 경우 말 그대로 쿼리를 통해 뷰를 검색하지만 REST는 여러 유형의 리소스를 처리하도록 설계 되었기 때문에 의도적으로 더 높은 수준으로 추상화됩니다.

REST 사양은 API가 최근에 많이 사용하기 시작했지만 상당히 앞선 생각입니다.

REST 프로토콜에 대한 자세한 내용은 " Haters Gonna Hate HATEOAS "를 참조하십시오.

최신 정보:

@Shauna는 내 추론에 흥미로운 구멍을 지적했습니다. 아무 없다 진정한 권리의 방법은 많은 형태를 사용할 수있는 것으로 간주합니다. 나는 그것에 대해 조금 더 생각했고 데이터를 다른 표현으로 변환하는 것이 목적이므로 변환을 새로운 MIME 유형으로 정의하는 것이 좋습니다.

예를 들어 URI를 다음과 같이 나타낼 수 있습니다.

/customer/{id}+print

응답 Content-Type을 text / html + print로 설정할 수있는 위치. 그러면 향후 더 많은 변환을 정의 할 수도 있습니다.

예를 들면 다음과 같습니다.

// for application/json
/customer/{id}+json

// for application/atom+xml
/customer/{id}+atom

어느 쪽이든, 모든 형태가 허용됩니다. 결정하는 구현은 개인 취향 및 서버 기능에 따라 다릅니다.

제쳐두고 : 혼란 스러울 것 같아서 명확히하겠습니다. 'print'query-parameter 및 / 또는 content-type은 리소스 변환 방법을 지정하는 데 사용됩니다. 실제 인쇄 작업을 트리거하는 방법이 아닙니다. 보안상의 이유로 하드웨어 수준 액세스는 항상 사용자 / 클라이언트 / 브라우저에게 맡겨집니다.