5장. 실제 디자인
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
API 패러다임, 보안 및 모범 사례에 대한 지침을 제공했으니 이제 API 설계에 대한 실제적인 실습을 해볼 차례입니다. 이 장에서는 책의 첫 번째 부분에서 다룬 모든 내용을 바탕으로 가상의 예제를 사용하여 다양한 고려 사항을 살펴봅니다.
또한 효과적인 설계 프로세스를 만드는 방법에 대한 인사이트를 제공하여 사용 사례에 관계없이 스스로 API를 설계할 수 있도록 지원합니다.
이 섹션에서는 디자인 결정을 내릴 때 사용자 경험에 중점을 두고 있습니다. 오늘날의 소비자들은 단순히 일을 처리하는 제품뿐만 아니라 자신의 필요와 라이프스타일에 맞는 우수한 제품 경험에 익숙해져 있습니다. 경험의 질에 대한 높은 기대치는 사람들이 구매하는 제품에 국한되지 않습니다. 이는 그들이 사용하는 앱과 API를 사용할 때 기대하는 개발자 경험으로까지 확장됩니다.
우리는 비즈니스와 회사를 구축할 수는 있지만, 우리 자신을 위해 API를 설계하지는 않습니다. 데이터를 수신하는 시스템, 그리고 더 중요한 것은 이러한 시스템을 구축하는 사람들을 위해 API를 설계합니다. 개발자가 우리가 제공한 데이터를 사용할 수 없다면 결국 유용한 디자인을 만드는 데 실패한 것입니다.
다음 섹션에서는 두 가지 시나리오를 통해 사용자 중심 디자인 프로세스를 시작하는 방법과 그 과정에서 피드백을 받는 방법을 살펴봅니다. 디자인에는 여러 가지 방법론이 있으며, 다음 프로세스는 단순히 시작하기 위한 프레임워크입니다. 이 특정 방법론의 가장 중요한 측면은 궁극적으로 API 사용자에게 도움이 되는 결정을 내릴 수 있는 방식으로 피드백을 요청하도록 설계되었다는 점입니다.
자신만의 예시를 따라 하고 싶다면 부록 A를 사용하는 것이 좋습니다.
시나리오 1
이 장의 첫 번째 부분( )에서 사용할 간단한 가상의 시나리오를 통해 실제적인 예를 살펴보겠습니다:
당신은 빠르게 성장하는 이미지 아카이브 스타트업인 MyFiles의 수석 엔지니어입니다. 이 회사의 주요 제품은 개인 사용자와 회사가 데이터를 비공개로 보관할 수 있게 해줍니다. 새로운 사용자가 꾸준히 유입되고 있고 아카이브 메타데이터가 많이 쌓이고 있기 때문에 여러분과 팀은 API를 만들고 게시하는 데 큰 잠재력이 있다고 생각합니다. 수석 엔지니어인 여러분은 다음 분기 내에 새 API를 출시해야 하는 임무를 맡게 되었습니다.
비즈니스 목표 정의
코딩이나 API 사양 작성을 시작하기 전에 잠시 시간을 내어 두 가지 질문, 즉 해결하려는 문제는 무엇이며 이 API를 구축함으로써 어떤 영향을 미치고 싶은가? 이 두 가지 질문에 대한 답은 비즈니스뿐만 아니라 사용자의 요구사항에 초점을 맞춰야 합니다.
첫 번째 질문에 대한 답변은 제품 또는 기술 사양의 맨 위에 명시할 수 있을 정도로 간결해야 합니다. 문제가 고객과 비즈니스에 어떤 영향을 미치거나 관련되어 있는지에 대한 정보가 포함되어야 합니다.