API
API 는 Application Programming Interface의 약자이며 Frontend clients, Backend Systems, Internal systems 등이 시스템의 자원을 사용하기 위한 Interface이다. API는 공개범위에 따라 Public, Private, Partner API로 나뉜다. Public API는 모든 사람들에게 공개된 APId이고 Private API는 내부적으로만 사용되는 API이며 Partner API는 비지니스적인 관계를 맺고있는 단체만이 사용할 수 있는 API이다.
API를 사용하게 되면 다양한 이점이 있다.
1. 쉽고 빠르게 시스템을 사용할 수 있다.
2. 내부 설계를 몰라도 사용할 수 있다.
3. API를 정의해두기만 하면 시스템이 완벽하게 구현되지 않아도 client가 작업을 진행할 수 있다.
4. 시스템의 내부 구조를 더욱 쉽게 설계할 수 있다.
API를 설계할때 다음과 같은 점을 고려하면 좋다.
1. Complete Encapsulation
API는 내부 디자인이나 구현과 독립적으로 개발되어야한다. 그래서 후에 API를 변경하더라도 문제가 없게 해야한다.
2. Easy to Use
사용하기 쉽도록 단순하게 설계해야한다. 특정 데이터에 접근하는 방법은 고유하게, action/resource를 잘 표 현하는 이름을 사용, 필요하고 일관된 정보만 제공해야한다.
3. Keeping the Operations Idempotent
여러번 호출되더라도 결과에 추가적인 영향을 줘서는 안된다. API는 주로 네트워크를 통해 사용되기 때문에 메시지의 손실, 응답의 손실 혹은 시스템의 문제가 발생할 수 있다. 그래서 네트워크와 decoupling하기위해 멱등성을 보장하는 것이 좋다.
4. Paging
응답 데이터가 필요이상으로 큰 경우 paging 기능을 사용하는 것이 좋다. Paging을 사용하면 client는 Offset과 maximum response size를 담아 요청을 보내야한다.
5. Asynchronous Operations
bigdata analysis와 같은 response time이 길것으로 예상되는 operation은 비동기적으로 처리하는 것이 좋은 방법이 될 수 있다. 이 경우 client는 요청하는 즉시 Identifier의 정보를 포함한 응답을 받고 작업의 진행도와 현 상태를 알기 위해 Identifier를 사용할 수 있다.
6. Versioning
이상적인 API는 API의 변경 없이 내부 구현 및 디자인을 변경하는 API이다. 하지만 실제로는 미래의 상황을 모두 예측할 수 없기 때문에 여러 버전의 API를 유지하면서 점진적으로 변경하는 방법을 사용할 수 있다.
RPC
RPC(Remote Procedure Call)는 API의 한 종류이다. RPC는 프로그래머 입장에서는 로컬 함수를 호출하는 것과 동일하게 느껴질 수 있다. 이를 location transparency라고 한다. 또한 RPC는 다양한 언어를 지원하기 때문에 서로다른 언어로 쓰인 application도 RPC를 통해서 상호작용할 수 있다.
RPC는 IDL(Iterface Descriptino Language)를 통해 서버와 클라이언트 사이의 통신에 대한 스키마를 제공한다. RPC Code Generation Tool은 IDL을 참고하여 각 머신에 맞는 Stub을 생성한다. 여기서 Stub은 클라이언트 혹은 서버에 파라미터와 같은 데이터를 각 머신에 맞게 변경해주는 코드를 말한다.
RPC는 이러한 식으로 수 십년간 사용되었다. 바뀐점이 있다면 framework, 세부 구현방법, 효율성 정도이다. API 개발자 입장에서 해야할 것은 적절한 famework를 정하고 해당 framework의 IDL을 이용해 API에 맞게 작성하면된다.
RPC의 장점은 편하다는 것이다. 일단 Stub을 생성하면 local method를 호출하듯이 사용하면된다. 그리고 통신과정에서 Failure가 발생한 경우 해당 언어에 맞는 방식으로 error 혹은 exception을 발생시킨다.
반면 RPC의 단점은 local method에 비해 느리고 신뢰성이 낮다는 점이다. 비동기 방식으로 처리하여 느린 단점을 일부 해결할 수 있다. 신뢰성을 보장하지 못할수도 있는 이유는 다른 회사의 머신이 우리 시스템과 통신할 수도 있기때문이다. 신뢰성 문제를 완벽히 해결할 수 없지만 멱등한 연산을 지원하는 방법으로 일부 해결할 수 있다.
RPC는 두 백엔드 시스템간의 통신에 많이 사용된다. 다른 회사에 API를 제공해야할 경우, 대규모 시스템의 서로 다른 component끼리의 통신, 네트워크 통신을 추상화하고 처리에 집중하고 싶을때 권장된다. 반면 네트워크 통신을 추상화하고 싶지 않거나 HTTP cookies, headers의 이점을 활용하고 싶을때, action위주가 아닌 data-centric API를 설계할때는 권장되지 않는다.
