많은 친구들은 처음 제품 관리자가 되었을 때 이미 하고 있던 업무에 매우 능숙했지만, 여전히 개발자로부터 "왜 이렇게 많은 요구 사항이 있고, 그렇게 많은 인터페이스가 완성되지 못하는가?"라는 불만을 듣게 되었습니다. 매니저님이 헷갈리는 표정으로 표현해주실 수 있나요? 인터페이스? 그것은 무엇입니까? 이미 문서에 페이지 기능을 자세하게 적어두지 않았나요?
실제로 시스템 수준에서는 카피라이팅 및 버튼과 같은 눈에 보이는 콘텐츠 외에도 콘텐츠 인터페이스 아래에 종종 API라고 부르는 논리적 체인이 많이 숨겨져 있습니다 . 이 글은 API에 대한 기본 지식과 제품 관리자의 구체적인 비즈니스 시나리오를 바탕으로 API를 더 잘 이해하고 사용함으로써 개발자와 보다 효율적으로 협력할 수 있도록 도와줄 것입니다.
API란 무엇입니까?
API(응용 프로그램 인터페이스)는 서로 다른 응용 프로그램이 서로 통신할 수 있도록 정의된 규칙 집합입니다. 이는 시스템 간 데이터 전송을 처리하는 중간 계층 역할을 하여 기업이 애플리케이션 데이터와 기능을 외부 제3자 개발자, 비즈니스 파트너 및 회사 내부 부서에 공개할 수 있도록 해줍니다.
이미지 출처: CSDN@tbprice
API의 작동 방식은 실제로 이해하기 쉽습니다. API가 어떻게 작동하는지 WeChat 결제를 통해 설명하면 쉽게 이해할 수 있습니다. 테이크아웃을 주문하면 시스템에서 "WeChat 결제 사용" 또는 기타 유형의 제3자 결제 방법을 묻는 메시지를 표시합니다. 이 결제 기능은 API를 사용하여 완료됩니다. 결제 버튼을 클릭하면 정보를 검색하기 위한 API 호출(요청이라고도 함)이 이루어집니다. 요청은 요청 동사, 헤더 및 때로는 요청 본문을 포함하는 API의 URI(Uniform Resource Identifier)를 통해 애플리케이션에서 웹 서버로 처리됩니다.
API는 상품 웹페이지로부터 유효한 요청을 받은 후 외부 프로그램이나 웹 서버, 즉 제3자 결제 시스템을 호출합니다. 서버는 요청된 정보가 포함된 API에 응답을 보냅니다. API는 초기 요청 애플리케이션(이 경우 제품 웹사이트)으로 데이터를 전송합니다. 데이터 전송은 사용하는 웹 서비스에 따라 다르지만 요청과 응답은 모두 API를 통해 발생합니다. 이러한 전송은 사용자 인터페이스에 표시되지 않습니다. 즉, API가 컴퓨터나 애플리케이션 내에서 데이터를 교환하고 사용자에게는 원활하고 원활한 연결로 나타납니다.
API는 어떻게 분류되나요?
통신 시나리오가 변경됨에 따라 API의 분류 차원도 달라집니다.
- API 제공업체에 따라 자체 소유 API, 타사 API(예: 신원 인증 , SMS 서비스 , 결제 서비스 , AI 대형 모델 등)로 구분됩니다.
- API 기술속성에 따라 구분: 시스템 API(예: 캐싱, 타이밍, 알림, 모니터링 등), 비즈니스 API(멤버십 API, 상품 API, 콘텐츠 API, 트랜잭션 API 등), 플랫폼 API(개별 로그인 API) , 검색 API, AI 고객 서비스) API 등).
- API 호출 방식에 따라 동기식 API, 비동기식 API로 구분됩니다.
- API 세분화에 따라 구분: 서비스 API(예: Meituan Takeaway API , Taobao Mall API, JD Express API 등), 기능적 API(예: 짧은 체인 API , 위치 API , 기업 인증 API 등).
- API가 외부 세계에 개방되어 있는지 여부에 따라 내부 API, 개방형 API로 구분됩니다.
제품 관리자는 어떤 시나리오에서 API를 설계해야 합니까?
- 인터넷 기반 애플리케이션(SPA 애플리케이션, APP 애플리케이션, 소형 프로그램, 스마트 기기 애플리케이션 등)을 개발할 때 기술 아키텍처는 기본적으로 클라이언트-서버 모델입니다. 이때 서버는 기본적으로 API이고 제품 관리자입니다. 사업에 대해서만 설명하면 됩니다.
- 업스트림과 다운스트림 사용자에게 기술적인 인터페이스를 제공할 때 기본적으로 API 형태로 제공됩니다. 이때 제품 관리자는 API를 설계하고 정의해야 합니다.
- 엔터프라이즈 서비스가 수익화되어 API로 제공되는 경우 제품 관리자는 API를 설계하고, API를 정의하고, API 가격을 책정하는 등의 작업을 수행해야 합니다.
제품 관리자는 어떤 시나리오에서 타사 API를 사용합니까?
기업이 디지털 시스템을 개발할 때 비용 요인, 데이터나 자원 보유 요인, 기술적 역량 요인 등으로 인해 모든 서비스를 자체적으로 개발하는 것은 불가능하며, 오픈 소스 코드를 광범위하게 사용하여 구축할 수도 없습니다. -party API는 피할 수 없는 선택이 되었습니다.
로그인과 같은 일반적인 기본 시나리오: 애플리케이션을 설계할 때 가장 기본적인 기능은 사용자의 로그인 기능입니다. 사용자는 각 소프트웨어에 별도의 계정을 등록할 필요가 없지만 WeChat, QQ, Alipay 및 기타 계정을 사용하여 로그인할 수 있습니다. 응용 프로그램. 유사한 시나리오에는 KYC 인증 , Single Sign-On, 보안 관리, 자금 수집 및 지불, 소셜 공유, 사용자 커뮤니케이션 등이 포함됩니다.
여행 예약 등 플랫폼 리소스를 활용한 시나리오 : 주요 여행 플랫폼 소프트웨어의 기본 기능은 항공편 및 호텔 정보를 집계하고 날짜별로 다른 가격을 표시하는 것입니다. 보통 이런 데이터는 수천 개의 웹사이트와 홈페이지에서 나오며, 이 서비스 역시 API를 통해 완성됩니다. 유사한 시나리오에는 특급 배송 및 물류 , 테이크아웃 플랫폼, 여러 주요 전자상거래 플랫폼 등이 포함됩니다. 기업은 타사 API를 사용해야 합니다.
AI 대형 모델 등 제3자의 기술 역량을 활용한 시나리오 : AI 대형 모델은 24년 만에 새로운 인기를 끌며 대부분 기업이 직접 개발할 수 없어 주로 활용하게 된다. 유사한 시나리오에는 클라우드 컴퓨팅 기술, 블록체인 기술 , 빅 데이터 기술, 스토리지 기술 등도 포함됩니다.
CRM과 같은 엔터프라이즈 SaaS 애플리케이션 사용 : CRM(고객 관계 관리 도구)과 같은 플랫폼에는 기업이 메시징, 소셜 미디어, 이메일 애플리케이션 등 이미 사용하고 있는 애플리케이션과 통합할 수 있는 많은 내장 API가 포함되어 있는 경우가 많습니다. 이를 통해 영업 및 마케팅 작업을 수행하기 위해 다양한 애플리케이션 간을 전환하는 데 소요되는 시간이 크게 줄어듭니다. 유사한 시나리오에는 금융 SaaS, 인간 SaaS, 사무실 SaaS, 마케팅 SaaS 등이 포함됩니다.
제품 관리자는 좋은 API 제품 문서를 어떻게 작성합니까?
제품 PRD의 주요 독자는 백엔드 개발(RD), 프론트엔드 개발(FE), 인터랙션 디자이너(UI, UE), 테스트(QA)입니다. 이들은 PRD에서 완료하는 데 필요한 작업 목표를 얻습니다. , 이를 활용하여 기본 계획을 설계합니다.
이전 기사에서는 API 지식을 배웠고 개발자와 소통할 수 있는 언어를 갖추었습니다. 이제 개발자가 우리의 요구 사항을 이해할 수 있도록 이 지식을 요구 사항에 대한 설명으로 변환해야 합니다.
다음은 구체적인 경우입니다. 우리가 전자상거래 플랫폼의 제품 관리자이고 이제 사용자 주문 생성 기능을 구현하기 위해 새로운 API를 설계해야 한다고 가정합니다. API 제품 문서를 작성할 때 다음 측면을 고려해야 합니다.
- 인터페이스 기능 설명 : 먼저 이 API의 기능, 즉 사용자 주문 생성이 무엇인지 명확히 해야 합니다. 입력 매개변수, 출력 결과 등을 포함하여 함수를 문서에 자세히 설명합니다.
- 파라미터 설명 : 주문 생성 기능에는 사용자 정보, 상품 정보, 결제 정보 등의 파라미터가 포함될 수 있습니다. 문서에 가능한 모든 매개변수를 나열하고 의미, 유형, 각 매개변수가 필요한지 여부를 설명합니다.
- 요청 예시 : 개발자가 주문 생성 기능을 구현하기 위해 API를 호출하는 방법을 보여주는 몇 가지 특정 요청 예시를 제공합니다. 개발자가 명확하게 이해할 수 있도록 예제에서는 다양한 상황의 매개변수 조합을 다루어야 합니다.
- 반환 결과 : 성공, 실패 등 API를 호출한 후 어떤 종류의 반환 결과를 얻게 되는지 설명합니다. 성공한 경우에는 반환된 주문 정보를 자세히 설명해야 하며, 실패한 경우에는 실패 이유를 설명해야 합니다.
- 오류 코드 정의 : 개발자가 API 호출 시 오류 코드를 기반으로 문제를 빠르게 찾을 수 있도록 가능한 오류 코드와 그 의미를 정의합니다.
- 보안 고려사항 : 사용자 개인정보, 결제 등 민감한 정보가 포함된 API의 경우 보안을 고려해야 합니다. HTTPS 프로토콜 사용, 매개변수 암호화 등 사용자 정보의 보안을 보장하는 방법을 문서에 설명합니다.
위의 자세한 설명을 통해 제품 관리자는 명확하고 완전한 API 제품 문서를 작성하고 개발자에게 요구 사항을 효과적으로 전달하며 필요한 기능을 올바르게 구현할 수 있는지 확인할 수 있습니다.
API에 관해 개발팀과 어떻게 소통하나요?
통일된 표준
프로젝트에는 의사소통이 필수입니다. 개발 파트너와 연결하기 전에 제품 관리자는 더 나은 수정 및 후속 조치를 위해 표준과 방법을 통합하는 데 주의를 기울여야 합니다.
통합 플랫폼
iPaaS 플랫폼 및 API 게이트웨이와 같은 최신 플랫폼 의 도움으로 기업은 먼저 기본 기술 수준에서 구현 일관성을 설정하고 플랫폼 기능을 활용하며 기술 복잡성을 무시하고 비즈니스 자체에 집중합니다.
통합 도구
기술 인력이 API 설계를 수행할 때 API 설계 도구를 사용하여 제품 관리자, 개발자 및 테스터가 공통된 관점에서 통신, 프로그래밍, 업그레이드 및 유지 관리할 수 있습니다.
"Qing Yu Nian 2"의 불법 복제된 리소스가 npm에 업로드되어 npmmirror가 unpkg 서비스를 중단하게 되었습니다. Zhou Hongyi: Google에 남은 시간이 많지 않습니다. time.sleep(6) 여기서는 어떤 역할을 합니까? 리누스는 '개사료 먹기'에 가장 적극적입니다! 새로운 iPad Pro는 12GB의 메모리 칩을 사용하지만 8GB의 메모리를 가지고 있다고 주장합니다. People's Daily Online은 사무용 소프트웨어의 마트료시카 스타일 충전을 검토합니다. "세트"를 적극적으로 해결해야만 Flutter 3.22 및 Dart 3.4 출시가 가능 합니다. 'ref/reactive'가 필요 없는 Vue3의 새로운 개발 패러다임, 'ref.value'가 필요 없음 MySQL 8.4 LTS 중국어 매뉴얼 출시: 데이터베이스 관리의 새로운 영역을 마스터하는 데 도움 Tongyi Qianwen GPT-4 수준 메인 모델 가격 인하 97% 증가, 1위안 200만 토큰