안정된 끝점 명명 규칙

Question

나는 REST 끝점이 동사 대신 명사가되어야한다는 것을 알고 있지만 때로는 약간의 편차가 허용됩니까?

제품을 게시해야하는 엔드 포인트를 상상해보십시오 (웹 페이지에서 보이게하거나 대기열에 항목을 추가 할 수 있음).

이 문제를 해결하는 방법은 두 가지가 있습니다.

1) PUT api/products/1/publish - 나는 명시 적이기 때문에 그것을 좋아하고 백엔드의 복잡성을 피하고 스스로 문서화합니다.

2) PATCH/PUT/PATCH API를/제품/1

{ 
    "color": "green", 

    //some properties removed for brevity 

    "ispublished" : true 
} 

두 번째 방법은 포스트 본체에 isPublished 필드를 추적하는 백엔드 서비스를 필요로하고는 사실, 처음으로 이성을 상실했을 때 출판 과정. 이것은 좀 더 복잡하고 더 많은 유지력을 느낍니다.

제 질문은 REST 관점에서 첫 번째 방법을 사용하는 것이 좋습니까? 큰 단점이 있습니까?

Answer 1

기술적으로 RPC 스타일에 따라 URL에서 동사를 사용하지 못하게하는 방법은 없습니다. 개념적으로는입니다. REST가 어떻게 설계되어야하는지는 아닙니다.

REST는 다시 표상 S 탓에 T를 ransfer을 의미합니다. 이 아키텍처 스타일은 resource-oriented이고 프로토콜에 독립적이지만 HTTP 프로토콜을 통해 구현되는 경우이 자주 입니다.

HTTP 프로토콜을 통해 REST 응용 프로그램을 구현할 때 리소스는 URI로 식별되며 해당 리소스를 통한 작업은 HTTP methods (다른 동사가 필요하지 않음)으로 표시됩니다. 자원의 상태를 변경하려면 서버에 자원의 새로운 상태에 대한 표현을 보내야합니다. 표현은 JSON, XML 또는 자원의 상태를 나타낼 수있는 다른 형식 일 수 있습니다. 아래의 인용을 참조하십시오

5.2.1.2 Representations

REST 구성 요소가 자원에 대한 작업을 수행하는 자원의 현재 또는 구성 상태를 캡처하는 표현을 사용하고 구성 요소 간의 표현을 전송하여. 표현은 일련의 바이트와 해당 바이트를 설명하는 표현 메타 데이터입니다. 표현에 일반적으로 사용되지만 덜 정확한 이름은 문서, 파일 및 HTTP 메시지 엔터티, 인스턴스 또는 변형을 포함합니다.

[...] 요청 된 리소스, 요청 된 리소스 또는 다른 자원의 값의 원하는 상태의 현재 상태를 표시 할 수있다 주어진 표현 ...]

따르는 본 접근 방식 인 경우 product 리소스는 status 하위 리소스를 가질 수 있습니다. 사용자의 필요에 따라 은 draft, published, inactive ...와 같이 다른 값을 가질 수 있습니다.

그런 요청 페이로드에 전송 된 JSON으로 status 하위 자원의 상태를 대체 할 PUT를 사용 : "게시"

PUT /api/products/1/status HTTP/1.1 
Host: example.org 
Content-Type: application/json 

{ 
    "value" : "published" 
}