OData 기초 – REST based APIs

2018.12.05 13:24SAP Story


낭만테란

ABAP 기반으로 회계및 물류 시스템을 구축했던 모든 SAP ERP 컨설턴트들에겐 생소한 개념이 등장하였다.
결론부터 정하면 "REST" 방식은 생성/변경/조회/삭제 라는 액션(이벤트)를 별도의 URI ( URL  에 # 을 붙이고 뒤에 액션별 자원할당 )을 사용하는 방식이다. 기존과 다른점은 URL 내에서 CRUD 이벤트를 트리거 하는 방식이 아니라
아예 #이후의 자원할당이 새로 된다는 점이다.
이는 SAP 트랜잭션 베이스와 묘하게 닮아 있다.
VA01, VA02, VA03 과 같이 생성/변경/조회 티코드가 따로 존재하여 각각의 목적에 맞게 사용하는 것처럼 REST 방식
또한 이를 액션으로 구분하여 별도의 자원으로 URI 매핑을 통해 (마치 티코드를 달리 가져가는것처럼 ) 거래를 일으킨다는 점이다.
이 개념을 아는 것은 매우 중요하다.
앞으로 구현할 OData 의 체계가 그러하기 때문이다.
<예시> 구매발주 현황 OData 구조


자원 할당은 데이터 모델에 직접 참조하거나 CDS 기반의 SADL ( Service Adaptation Description Language ) 혹은 BOPF-SADL 의 복잡한 비즈니스 오브젝트를 가져올 수 있는데 이는 ABAP 기반의 SAP 컨설턴트 그리고 개발자들에게 아주 익숙한 분야이다. 다만 OData Service Implementation 의 Runtime Artifact의 구조를 이해하는데 생소함이 있을 것으로 예상한다.
다시 아래 그림을 보면서 구매발주 현황 OData 구조의 Service Implementation 의 액션을 자원의 관점에서 살펴보자.


#posts 부분을 Service "Update"의 자원이라고 생각해보면 세션메니저에 해당하는 메인 URL 그리고 tcode 에 해당할 수 있는 자원 부분으로 이해할 수 있다. ( 정확한 표현은 물론 아니다. 이해를 돕기 위한 설명이다. )
목적성을 본다면 결국 서비스 수행인데 ( 조회, 변경,생성,삭제와 같은 액션을 통하여 ) 그 서비스를 위해 앞의 데이터 모델 부분의 모델링이 필요하고 이를 적용하기 위해서 각 자원별 프로세싱 영역이 이후 설명될 OData 의 Back-End에 대한 대부분이 될것이다.
구매정보 레코드를 관리하는 앱이 있다고 가정해보자.
필요한 항목은

    1. UX - 화면 구성 (프레임워크)
    2. 개별 액티비티 (조회/생성 등의 이벤트 향후 액션으로 통일 )
    3. 데이터 모델 ( EINA, EINE 기반으로 Material Info, Supplier BP, Purchasing Org... )
    4. 액션 수행 담당 ( REST 의 방법대로 각 자원에서 전달된 파라미터로 부터 BAPI 등을 수행 )
    5. 일치성 유지 : 화면과 버퍼, 그리고 Persistent Data 간의 동시성, 일관성 및 정합성
Odata 의 Front End 분야는 매우 다양하다. 자바진영으로 대표되는 각종 EP 프레임워크가 될 수도 있고 모바일 앱이
될 수도 있다. Odata 는 이를 위해 프로토콜을 Open Data Protocol 이름 그대로 호환성을 극대화 하였다.
(참조 : Odata 의 기원   
         SAP가 아니다. MicroSoft가 International Standard 를 위해 만들다 )
우린 장차 SAP ERP 구축 및 유지보수가 주요 과업이므로 Odata 는 필연적으로 Fiori 를 향할 수 밖에 없다는 점을 이미 알고 있다. 당분간 Odata 중심으로 연재하려 하는데, 주로 Front-End 보다는 Back-End 에 주안점을 두고 비즈니스 요구사항을 어떤 방식으로 구현해 나갈지에 대한 개념적 접근을 하려 한다. 게으리지 말아야 할텐데...
앞서 REST 개념을 쉽게 설명하기 위해 세션메니저-트랜잭션코드 로 설명하였는데 정확한 REST 개념을 사전적 정의 그대로 SAP 파워 블로그의 글을  살펴보며 이 글을 마무리 한다.

What is REST?  ( REST is REpresentational State Transfer )  
REST is resource based unlike RPC or SOAP which are action based. In SOAP you will have a request to get material data whereas in REST, material will be identified as a resource using URI and then use HTTP verbs to determine which operation shall be performed on the resource. It is important to note here that it is possible to have multiple URIs pointing to the same resource.
Representation of the resource is the not the resource itself but only a representation.
The term representation is how the resources are manipulated in a rest based architecture
Representations depicts parts of the resource state which are transferred between client and server in mostly JSON or XML format. Client will typically have enough information to manipulate the resource on the server.  For example, if Person is modelled as a resource and there is a service to get contact information of a person then the representation that you will get of that Person would be Name, Address and Phone details in JSON or XML format.
The Six Constraints
Following are the six constraints defined which are attributes of a RESTful API.
1. Uniform Interface
Uniform Interface is fundamental to the design of any REST based service. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently.
What that means is that it should be possible to identify the individual resource in the request, for example using URI. Once the Client has a representation of the Resource then, it should have enough information to update or delete the resource. And that the Client should not assume that any particular action is available on a resource beyond those described in the representation received from the server previously.
2. Stateless
The Server should not contain any Client state. It is possible to process a request only if they are self-descriptive and that the request should have enough context to act upon. For example, if the Person resource address needs to be updated then it is required that the Client pass on the particular Person resource details in the request for which it has received the representation from the Server in the previous request. If the state has to be maintained, it should be at the Client side.
3. Client-Server
We have already established this constraint that the RESTful architecture is a Client-Server architecture. Resource representations are transferred between client and server. We should always keep at the back of our minds that the Client of RESTful APIs will not have direct connects to the Resources.
4. Cacheable
Another constraint on a RESTful API is that any response that is coming from the Sever should be cacheable on the Client side. Caching could be implicit, explicit or negotiable. Implicit and Explicit caching is self-explanatory whereas Negotiable caching means that the Server and Client agree on how long a representation can be cached on the Client.
5. Layered System
The constraint of Layered System is closely related to the above two constraints of Client-Server and Cacheable. It suggests that the Client of a RESTful API should not assume that there will be a direct connection between the client and the server. There could be multiple layers of software or/and hardware in between the two. The Client need not know whom exactly it is talking to and whether a response is coming from the server or is accessed from a local cache. This improves scalability.
6. Code on Demand
This constrains suggests that it should be possible that a Server can extend a Client temporarily. It means that Server can transfer logic to the client as representation to be executed at the client.
This is the only optional constraint.
A RESTful service needs to adhere to all of the above mentioned constraints (except Code on Demand) to be called as a RESTful API.