RESTful 계산기를 만들려면 어떻게해야합니까?

Question

RESTful 웹 서비스는 "모든 것이 자원으로 표현되고 주소 (URI)로 액세스 할 수 있음"이라는 신성한 아이디어를 기반으로하므로 CRUD 응용 프로그램에 적합 할 수 있습니다 (모든 예제는 목록 작성/업데이트에 대한 것입니다)/엔티티 삭제). 그러나 CRUD 연산과 아무런 관련이없는 간단한 계산기 RESTful 서비스를 만드는 것과 같은 다른 비즈니스 로직은 어떻습니까? 그런 REST 서비스에 좋은 디자인이 될 수 있을까요?

둘째, SOAP의 논리가 이미 완전한 의미를 갖는 경우 SOAP에 비해 REST를 사용하면 진정한 이점은 무엇입니까?

Answer 1

계산기 서비스는 RESTful 방식으로 모델링하는 것이 간단합니다. "CRUD"의 "R"은 "read"를 의미하며 "read"는 "compute"를 의미 할 수 없습니다. 그래서 간단한 Reverse Polish 계산기 서비스는 GET을 통해 액세스 할 수 있습니다 :

3 
4 
+ (URL-encoded as %2B) 

멱등, 안전하고 캐시 요청의 :

는

GET https://calc.com/rpnCalc?3&4&%2B 
7 

단순히 위의 URI 방식은 GET 요청에 대한 세 개의 매개 변수를 추가합니다. 이것이 계산에 많은 시간이 소요되는 미친 듯이 복잡한 수학 쿼리 인 경우 이러한 쿼리를 즉시 사용할 수있는 HTTP 프록시로 라우팅하고 동일한 URI를 반복적으로 쿼리해야하는 경우 사전 계산 된 값을 즉시 반환하는 데 사용할 수 있습니다.

수행해야 할 계산의 종류에 따라 매우 복잡한 쿼리를 (요청 본문으로 쿼리를 전달하는) Calculator 리소스에 POST 할 수 있으며 서버가 URI를 "결과"리소스로 반환 할 수 있습니다 그 결과를 가져 와서 페이지를 매길 수 있습니다.

두 번째로 SOAP의 논리가 이미 완전한 의미를 갖는 경우 REST over SOAP를 사용할 때의 진정한 이점은 무엇입니까?

SOAP의 복잡한 부분을 만들지 않고 curl과 같은 명령 줄 도구를 사용하여 위의 계산기 서비스에 액세스 할 수 있습니다. 타사 XML 라이브러리 또는 SOAP 툴킷을 사용하지 않고도 초 단위로 호출을 코딩 할 수 있습니다. HTTP 프록시와 같은 상품 도구를 사용하여 결과를 캐싱하고 성능을 향상시킬 수 있습니다. SOAP 상호 운용성이나 WS-I 호환성에 대해 걱정할 필요가 없습니다. 하이퍼 링크를 올바르게 사용하면 기존 클라이언트에 영향을 미치지 않고 서비스를 향상 시키거나 개선 할 수 있으며 다시 컴파일해야합니다. 버전을 유지할 WSDL이 없으며 몇 년 동안 유지해야하는 약한 계약이 없습니다. 클라이언트는 이미 GET/PUT/POST/DELETE이하는 일을 알고 있으며, 의미를 재정의하거나 다시 문서화 할 필요가 없습니다. XML 대신 JSON을 선호한다고 결정한 API 클라이언트는 HTTP의 내장 된 내용 협상 기능을 사용하여 얻을 수 있습니다. 나는 SOAP와 웹 서비스를 가지고 이러한 것들을 절대적으로 할 수 있습니다.

안녕하세요, SOAP이 필요에 맞는다면 사용해보세요. REST를 사용하면 많은 이점이 있지만 상황에 따라 적절하지 않을 수 있습니다. 최소한 REST가 적절한 책 like this one을 제공 할 수 있는지 알아보고 전체 기사를 얻은 후에 마음을 닦으십시오.

Answer 2

이것은 REST에서 명사와 동사 간의 긴장감의 좋은 예입니다. "add"또는 "adder"를 자원으로 사용하라는 제안은 대단히 순진합니다. 그것은 각 연산이 "가산기"또는 "감산기"에 대한 GET으로 수행된다는 것을 의미합니다. 물론 하나는 자원을 "계산"할 수 있지만 우리는 동사를 사용합니다. 우리는 명사 인 "calculator"또는 "answer"로 변경할 수 있지만 실제로는 아무 것도하지 않았습니다.

Answer 3

HTTP POST는 반드시 보존 된 리소스를 만들 필요는 없습니다. RFC 2616, section 9.5에서 우리는 발견 : POST 메소드에 의해 수행

액션은 URI에 의해 식별 될 수있는 리소스 발생하지 않을 수 있습니다. 이 경우 에 응답을 표시하는 엔터티가 포함되어 있는지 여부에 따라 200 (OK) 또는 204 (No Content) 중 하나가 적절한 응답 상태입니다.

즉, 계산 결과를 자체 URL에 유지하지 않고도 "계산 생성"에 대해 생각할 수 있습니다. 귀하의 API는 다음과 같이 수 : 이것은 당신이 제한된 길이의 클라이언트 또는 프록시를 통해 긴 계산을 제출하려고 할 때 중단됩니다 당신이 URL을 통해 "내용"을 통과하지 않는 장점을 가지고

Request: 
POST /calculations 
Content-Type: text/plain 

3 + 3/12^(3 * PI) 

Response: 
200 OK 
Content-Type: text/plain 

3.005454 

URL 또한 요청과 응답에 대해 서로 다른 표현을 지원할 수도 있습니다.

Answer 4

이 질문은 몇 살입니다. 그러나 여전히 많은 저의 동료들을 혼란스럽게하는 질문에 대한 것 같습니다. 우리는 모두를 만족시키는 해결책에 도달하지 못했습니다.

그러나 간단한 계산기의 경우 JAXRS 구현이 깨끗한 API를 제공한다고 생각합니다. 이러한 실현하는 것이 함께

---

/** 
* This class defines a CalculatorResource. 
*/ 

@Path("v{version}/calculators/{id}") 
@Named 
public class CalculatorResource { 

    private final Long value; 

    public CalculatorResource() { 
     value = 0L; 
    } 

    public CalculatorResource(Long initialValue) { 
     this.value = initialValue; 
    } 

    @GET 
    public Long getValue() { 
     return value; 
    } 

    @Path("+{value}") 
    public CalculatorResource add(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value + value); 
    } 

    @Path("-{value}") 
    public CalculatorResource subtract(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value - value); 
    } 

    @Path("*{value}") 
    public CalculatorResource multiply(@PathParam("value") Long value) { 
     return new CalculatorResource(this.value * value); 
    } 

} 

상기 URI는 식 읽기 쉽게 할 수있다.

예 :/api/v1/계산기/mycalc/+ 9/-4/* 3/+ 10 은 25를 반환합니다.