API를 만들 때 작은 함수와 많은 호출 또는 몇 개의 호출과 큰 함수를 사용해야합니까?

유지 관리하는 레일 플랫폼이 있습니다. 그 위에 다양한 웹 응용 프로그램이 구축되어 있습니다. 그러나 이제 고객은 사이트에 사용자를 유지할 수는 있지만 자동화 된 일부 작업을 활용할 수 있도록 API를 요청하고 있습니다.

이 플랫폼은 보험 응용 프로그램을 작성하고 온라인으로 구매할 수있을뿐 아니라 정책과 관련된 문서를 다운로드 할 수있는 방법을 제공합니다.

따라서 API를 빌드 할 때의 질문은 다음과 같습니다.

나는 많은 일을해야 할 때, 같이 validate하는을 만들고 user, user profile그리고 policy, 거의 같은 시간에. 4 개의 별도 API 호출을 작성하고 클라이언트가 4 개의 호출을 작성해야합니다. 또는 많은 매개 변수를 제외하고 클라이언트를 확인하고 동시에 3 가지를 모두 작성하여 클라이언트를 단순화하는 호출이 하나 있어야합니까?

이 경우 클라이언트는 필요한 모든 정보를 동시에 가져 오므로 응용 프로그램에 일시 중지되어 내 플랫폼에 대한 API 호출을 할 수있는 자연스러운 흐름과는 다릅니다.

이전에 많은 API를 사용하여 클라이언트 측에 있었지만, 내 직감은 클라이언트를 최대한 간단하게 만들고 한 번만 호출하도록하는 것입니다. 그러나 이것은 functionsAPI에서 다소 커져서 팬이 아닙니다.

이 문제를 어떻게 해결하겠습니까?

참고로 클라이언트 측에서 복잡한 API를 구현할 수있는 능력에 대해서는 확신이 없습니다.

둘 다 하는건 어때? 시스템의 기능을 노출 하는 " 낮은 수준 "(발언 할 수있는) API가 있고 클라이언트가 원하는 서비스를 노출하는 다른 "계층"이 있습니다. 이 계층은 필요한 낮은 수준의 API를 필요로하지만 클라이언트가 원하는 경우 여전히 노출됩니다.

업데이트 : 다른 사람들이 작성한 몇 가지 훌륭한 요점과 의견도 포함합니다.

1. 클라이언트가 더 작은 API 메소드 중 하나를 호출해야하는지 고려하십시오. 예를 들어 createUser를 호출하지 않고 createUserProfile을 호출 할 수 있습니까? 그렇지 않은 경우 해당 방법을 노출하지 마십시오. 감사합니다 NoobsArePeople2

2. 간단하지만 훌륭한 포인트. API에 무언가를 노출시키는 요점-노출을 풀 수 없습니다. 모든 것을 드러내는 것보다 기능하고 확장하는 데 필요한 최소한의 것을 드러내십시오. 그러면, 알몸으로 변화하는 것은 창피하고 어색 할 수 있습니다 . 감사합니다 MichaelT

당신이 잘못보고 있다고 생각합니다. 큰 걱정하지 마십시오 | 작은 전화 또는 많은 | 몇 번의 전화.

비즈니스 오브젝트 및 다음으로 수행 할 수있는 조치에 대해 생각하십시오. | 대한 | 그 물체에 대하여.

당신이있어:

• 사용자
• 정책
• 요금
• ...

따라서 해당 객체 주위에 API 호출을 작성해야합니다.

• User.Create
• User.UpdatePassword
• 정책. 확인
• ...

아이디어는 비즈니스 오브젝트 및 해당 조치를 기반으로 원자 또는 거의 원자 작업을 작성하는 것입니다. 이를 통해 비즈니스 오브젝트가 수행해야하는 작업을 수행하는 설계 및 코딩 호출을 단순화 할 수 있으며 이는 프로그래머의 정신 모델이나 기대와 일치합니다. 프로그래머 나 설계자가 비즈니스 분석가와 요구 사항을 논의 할 때 모두 동일한 용어와 일반적인 작업 흐름을 사용할 수 있습니다.

더 큰 올인원 유형 통화의 문제점은 부작용의 위험입니다. Policy.Create가 사용자를 생성하고 다른 작업을 트리거하면 프로그래머의 기대를 무너 뜨릴 수 있습니다. 마찬가지로 많은 작은 호출로 인해 프로그래머는 "단일"비즈니스 작업을 수행하기 위해 A, B, C를 호출해야합니다.

그리고 당신이 전화를 어떻게 명명하는지는 Rails와 당신의 지원 웹 서비스가 무엇을 지원할 것인지에 따라 결정됩니다.

보다 규범 적으로 설명하면 많은 매개 변수를 사용하고 백엔드에서 클라이언트에게 가려지는 여러 호출이있을 수있는 일부 호출이 생성됩니다. 또한 API가 기본 루틴의 래퍼에 지나지 않는 매우 빠르고 간단한 호출로 끝납니다.

당신의 직감이 옳다고 생각합니다-소비자를 위해 API를 간단하게 만드십시오. 어느 정도까지는 이것이 소비자 주도 계약 의 철학 입니다.

보다 구체적으로, API는 적절한 비즈니스 사용 사례를 공개해야합니다. 비즈니스 영역을 고려하십시오. 실제로 저수준 기능이 필요합니까? 캡슐화의 단점은 무엇입니까? API의 큰 함수는 그 자체로는 문제가되지 않습니다. 문제가되는 것은 소비자의 개입을 허용하기 위해 큰 기능이 작업을 분할해야하는 경우입니다.

개인적으로 저는 다음과 같은 API를 좋아합니다.

1. 일반적인 사용 사례를 쉽게 수행 할 수있는 방식으로 최적화
2. CRUD 작업 과 관련된 호출 은 일괄 처리 또는 일괄 처리 버전입니다
3. 반영 허용 (다른 컴퓨터 언어에 대한 플러그인 또는 바인딩을 작성하는 사람들이 프로세스를 자동화 할 수 있음)