내부 및 외부 API 아키텍처

19

내가 일하는 회사는 수년간 "유기적으로"성장한 성공적인 SaaS 제품을 유지합니다. 기존 제품과 데이터를 공유 할 새로운 제품군으로 라인을 확장 할 계획입니다. 이를 지원하기 위해 비즈니스 로직을 단일 장소 인 웹 서비스 계층으로 통합하려고합니다. WS 계층은 다음에 의해 사용됩니다.

웹 애플리케이션
데이터를 가져 오는 도구
API 자체가 아닌 다른 클라이언트 소프트웨어와 통합하는 도구

또한 자체 통합을 작성하는 데 사용할 수있는 고객이 사용할 수있는 API를 작성하려고합니다. 우리는 다음 질문으로 어려움을 겪고 있습니다.

내부 API (WS 계층이라고도 함)와 외부 API가 동일해야하며 보안 및 권한 설정을 통해 누가 수행 할 수있는 작업을 제어 할 수 있으며 외부 API가 내부 API를 호출하는 별도의 두 응용 프로그램이어야합니다. 다른 응용 프로그램처럼? 지금까지 우리의 논쟁에서 그것들을 분리하는 것이 더 안전 할 수 있지만 오버 헤드를 추가 할 것으로 보입니다.

다른 사람들도 비슷한 상황에서 무엇을 했습니까?

api web web-services

— 드류 굿윈
소스

SOA를위한 훌륭한 프레임 워크를 구입한다면이 모든 논쟁은 무의미하다. 자체 SOA 프레임 워크를 롤링 할 계획입니까? 왜? 성공적인 제품이라면 Oracle에서 JCAPS를 라이센스하지 않는 이유는 무엇입니까? 아니면 IBM의 WebSphere? 그러면 WS 계층의 보안이 어디에나 있고 투명 해집니다.

— S.Lott

1

@ S.Lott SOA 레이어를 작성하는 것은 그리 어렵지 않습니다. 이러한 플랫폼 중 어느 것도 REST 기반이 아닙니다. 2012 년 아닌가요? 그 끔찍한 '기업가'.

— Evan Plaice

도메인 모델 위에 서비스 계층을 두지 않는 이유는 소스 코드와 동일한 서비스를 내부적으로 사용할 수 있다는 것입니다.

— M.abuelezz

13

자신의 개밥을 먹는 것이 항상 좋습니다. 인증 및 권한 부여에 대한 오버 헤드를 고려하더라도 하나의 API가 두 개보다 유지 관리하기가 더 간단해야합니다.

— 동맥류 9
소스

4

나는 당신이 그것을 넣는 방식을 좋아합니다. 두 개의 분리 된 계층을 갖는 것은 궁극적으로 미래에 두 번이나 여러 장소에서 상황을 변경하고 추가 테스트를 수행하며 사물이 왜 동기화되지 않았는지 파악하려는 많은 광기의 의미를 의미합니다. 나는 당신의 대답을 투표를하기에 충분한 명성을 가지고 있다면, 나는 :) 것

— 드류 굿윈에게

5

Aneurysm9에 동의하지만 때때로 시스템의 모든 기능을 공개하고 싶지는 않습니다. 이 경우 두 개의 API를 사용하는 것이 바람직합니다 ... 하지만 이렇게 선택하면 모든 공통 기능이 동일한 API, IE를 공유하는지 확인하십시오. 하나는 다른 두 가지가 아닌 다른 버전의 확장 버전입니다. 코드 세트.

이 방법으로 공개 API를 크게 변경하지 않고도 새로운 것을 공개하고 사용할 수있게하면서, 개인적이고 민감한 실험적인 작업을 진행할 수있는 장소를 가지면서 자신을 위해 직접 사용할 수 있습니다.

— 뉴 토피아
소스

3

우리는 여기에 동의한다고 생각합니다. 보안 계층을 사용하여 기능의 상위 집합을 내부 사용자로 제한하십시오. 그렇게하면 API에 액세스 할 수있는 하나의 API가 있지만 여러 수준의 권한이 있습니다.

— Aneurysm9

내 응용 프로그램을 높은 권한으로 자체 사용자로 만들어서 직접 처리하고 처리하는 것에 대해 생각하고 있습니다. 내 뇌를 감쌀 까다로운. 나는 이것에 해먹 중심 개발 을 적용해야한다고 생각합니다 .

— AJB

4

나는 전에 (많은 시간) 이것을 만났고 내가 선호하는 일은 다음과 같습니다.

웹 사이트에서 BL을 꺼내십시오. 웹 사이트를 API 소비자로 만드십시오. 웹 사이트를 다른 API 클라이언트로 취급하십시오. 귀하의 API는 서비스입니다.

웹 사이트에만 특별한 API 메소드가 필요하다고 생각되면 다시 생각하십시오! 거위에 좋은 경우, 거더에 좋습니다. 실제로 웹 사이트에 대한 특수 기능이 정말로 필요한 경우 실제로 찾은 것은 "사용자 프로필"의 차이이므로 API가 여전히 "특수"기능을 지원해야하는 상황이지만 승인을 통해 제어합니다.

확신이 없습니까?

패러다임을 한 단계 더 발전 시키십시오 ...

전화 앱은 바이트 코드가 실행되는 플랫폼에서 실행되고, 앱은 전화에 있으며 HTTP / JSON을 통해 API 서비스를 소비합니다.

웹 사이트는 HTML + Javascript가 실행되는 플랫폼에서 실행되는 앱이며, 브라우저에 있으며 HTTP / JSON을 통해 API 서비스를 사용합니다.

같은 같은!

태블릿, TV, 기타 전화 플랫폼, 플러그인, 타사 앱, 매시업 등으로 확장하십시오.

많은 다른 사용자 경험이 모두 공통 API에 연결되었습니다.

앱은 API입니다. 웹 사이트는 하나의 클라이언트 일뿐입니다.

— 제이슨 글로버
소스

API 가 전체 응용 프로그램 계층이며 다양한 버전 (OS, 브라우저, 태블릿, 전화)이 API의 클라이언트 일 뿐이라는 것을 이해하면 A-Ha! 바로 지금.

— AJB

2

하나의 API 사용

서비스 API를 REST 계층으로 구현하는 경우 보호 된 경로에 인증을 추가하십시오.

너무 많은 '마법'에 구애받지 않는 개발 프레임 워크를 사용하고 싶을 것입니다. 많은 리버스 엔지니어링없이 직접 경로를 정의 할 수있는 것.

Node.js / Express, python / pylons, python / google 앱 엔진 등과 같은 것을 생각하십시오.

최근에 REST / Datastore API를 위해 Google App Engine에서 이것을 구현했지만 더 쉬울 수 있다고 생각하지 않습니다. 컨트롤러는 클래스로 구현되며 후속 HTTP 요청 (예 : GET / POST / PUT / DELETE)은 해당 클래스의 메서드로 구현됩니다. 데코레이터로 기본 인증을 구현했습니다. 따라서 @basicAuth 데코레이터를 연결하는 것만 큼 간단하게 요청에 인증 요구 사항을 추가 할 수있었습니다.

그렇게하면 들어오는 GET 요청을 공개하여 해당 모델의 동일한 컨트롤러에서 POST / PUT / DELETE 요청에 인증 요구 사항을 추가 할 수 있습니다.

REST에서 말하는 방법을 알고 있다면 REST 지원이 이미 웹 서버에 내장되어 있기 때문에 인생이 훨씬 쉬워집니다. 즉, HTTP는 REST API의 한 유형일뿐입니다. 유선으로 많은 데이터를 전송하는 경우 투명한 gzip 압축을 선택할 수도 있습니다.

— 에반 플라이스
소스

-1

첫 번째 인상은 API가 같아야하며 보안이 다른 계층에 있어야한다는 것입니다. 아마도 웹 프론트에서 처리됩니까?

— 베가이
소스

2

때때로 보안 문제는 단순한 암호화 및 트랜잭션 서명보다 훨씬 더 깊이 파고들 것입니다. 따라서 일부 또는 많은 보안 지향 요소가 기본 API에서 발생할 수 있습니다. 이것은 가능한 한 분리 된 상태로 유지하려는 데 동의합니다.

— Newtopian