728x90
반응형
일상 속 사물이 알려주는 웹 API 디자인이라는 책을 읽으며 정리한 내용입니다. 

 

프로그래밍 인터페이스 디자인하기

 

내용

  • API 목표를 프로그래밍 인터페이스로 변형하기
  • REST 리소스와 액션을 식별하고 매핑하기
  • 컨셉으로 API 데이터 디자인하기
  • REST API와 REST 아키텍처 스타일의 차이점
  • API 디자인에서 REST 아키텍처 스타일이 중요한 이유

 

REST: Representational State Transfer

GET, /products/{productId}, 200 OK 라는 용어들의 의미를 이해해야 프로그래밍 인터페이스를 디자인할 수 있다.

REST API는 REST 아키펙처 스타일에서 기반하고 있다.

 

REST API 소개

REST API 호출 분석

p123이라는 상품 카탈로그 정보를 REST 쇼핑 API를 통해 가져오고자 한다면 HTTP 프로토콜을 이용하여 커뮤니케이션해야 한다.

이 목표가 GET /products/{productId} 로 표현되므로 컨슈머가 위와 같이 리퀘스트를 보내야 하며 서버가 HTTP response로 응답(200 OK)을 반환한다.

경로: 서버상의 리소스를 식별할 수 있는 주소

HTTP 상태코드: request에 대한 응답

response 바디: 응답에 대한 콘텐츠

응답은 JSON 형태이나 단순히 JSON 데이터를 가져오려는 목적으로만 만들어진 것이 아님

 

HTTP의 기초사항

HTTP는 World Wide Web의 기초.

다양한 상황에서 HTTP 프로토콜을 사용한다. - GET/POST/DELETE 등

HTTP 요청에는 목적이 무엇이든 HTTP 메서드와 리소스 경로가 포함된다.

  • HTTP 메서드: GET / POST / DELETE / 등
  • 리소스 경로: 어떤 리소스에 접근하는지

 

REST API의 기초원리

상품 정보를 가져오는 목표를 실행하는 REST 쇼핑 API의 예에서, 

컨슈머는 HTTP 리퀘스트를 API 호스팅 서버에 보내야 한다.

이 리퀘스트는 GET HTTP 메서드를 사용해, /products/{productId} 경로로 식별되는 상품을 찾는다.

서버는 상품 데이터와 이를 나타내는 HTTP 상태 코드가 포함된 response를 함께 리턴한다.

결국! REST API는 HTTP 호출 그 이상의 행위를 하지 않는다. 

 

API 목표를 REST API로 변형하는 과정

(to be continued..)

728x90
반응형
728x90
반응형

사용자를 위한 웹 API 디자인하기

주제

  • 어떤 관점으로 API를 디자인해야 하는가?
  • 사용자 인터페이스를 디자인하듯 API 디자인하는 법
  • API의 실제 목표를 정확하게 결정하는 법
더보기

내가 만들었던 API는 목표 설정을 제대로 못했던 듯. 이번 장 내용에서 목표를 정확히 결정하고 API 디자인 시 가질 관점을 잘 생각해 봐야겠다 ㅇㅅㅇ!


API를 사용하는 사람들이 원하는 것이 무엇인지의 관점.

소셜 네트워크의 API는 사진 공유, 친구 추가, 친구 리스트 표시 등이 API의 목표이며 이러한 목표들이 효과적인 API를 디자인하는데 필요한 기능적 청사진 역할을 함

그렇기 때문에 목표 식별이 중요하며 서로 연관된 포괄적인 요구사항들을 정리할 수 있도록 컨슈머의 관점에 중점을 두어야 한다.

사용자가 얻을 결과에만 집중하는 것이 중요하다. 즉, 컨슈머 관점에서 사용하기 쉽도록 개발해야 한다.

 

API의 목표 식별 과정

API를 디자인할 때 고려해야 하는 점

  • 누가 API를 사용하는가?
  • 무엇을 할 수 있는가?
  • 어떻게 하는가?
  • 하기 위해서 무엇이 필요한가?
  • 끝나면 무엇을 반환하는가?

-> 사용자들의 요구사항을 수집하고, 그 요구사항을 깊이 파고 들어가 정확히 이해하며, 마침내 그 목표를 조금이라도 효율적이며 정확하게 달성해야 한다.

이때 누락된 목표나 사용자는 없는지 잘 확인해야 한다.

API 목표 캔버스를 사용하여 "누가", "무엇을", "어떻게", "입력", "출력" 목표"를 설정.

누가 사용자인지와 흐름들로부터 새로운 목표를 찾아내는 과정들이 중요하다.

 

API 디자인에서 피해야 할 프로바이더 관점

API는 근본적으로는 컨슈머와 프로바이더라는 두 개의 다른 소프트웨어 간의 데이터를 교환하는 방법을 의미한다.

프로바이더 관점에서 데이터의 체계와 이름을 그대로 API 목표와 데이터에 매핑하는 실수를 하기도 하는데, 이는 이해하기도 어렵고 사용하기도 어렵게 만든다.

데이터 모델과 조작에 관한 내용은 노출되면 안 된다.

내부 비즈니스 로직의 노출은 API의 컨슈머가 이해하기도 어렵게 하며 프로바이더에게도 위험하다.

숨겨야 하는 인적 조직을 API 디자인에 매핑시키지 않아야 한다.

 

요약

API 목표 목록은 포괄적이고 컨슈머 지향적이어야 하며 프로바이더 관점이 드어가서는 안된다.

728x90
반응형
728x90
반응형
더보기

'일상 속 사물이 알려주는 웹 API 디자인' 읽은 내용 정리

첫 글 쓰기 전에...

API 개발이야 여러 번 해 봤지만 제대로 설계를 하고 개발한 적은 거의 없다고 본다.

그저 개발하기 급하게 개발한 못난이 API 투성이.. ㅠㅠ 

그러다가 한 반년 전에 개발한 API를 봤는데 너무나도 엉망이라 ㅋㅋㅋㅋㅋ 진짜 너무나도 거지 같아서 새로 설계하고 다시 짜렸는데 반년 전의 나와 지금의 나의 다른 점은.. 크게 없으므로 제대로 공부를 좀 해보고 개발하려고 공부하려고 한다!

책은 그냥 이 전에 개발 잘하시는 책임님이 사시던거 기억해두고 따라 샀던 책이라 어디 구석탱이에 있던 게 생각나 꺼내왔다.

고럼 화이팅 하매~~~

 


1부. API 디자인의 기초

1장. API 디자인이란 무엇인가

 

API는 인터페이스로 시스템 간 통신을 위한 인터페이스로 작용한다.

스마트폰의 예시를 들어봤을때,

스마트폰 UI와 비교를 들었는데, 스마트폰 화면을 터치하여 모바일 애플리케이션과 사람 간의 상호작용하는 역할을 하는 UI가 애플리케이션이 다른 애플리케이션과 상호작용을 하기 위해 작용하는 프로그래밍 인터페이스인 API와 비교할 수 있다.

모바일 애플리케이션이 백엔드와 커뮤니케이션하기 위해 인터넷을 사용하는데 HTTP를 사용 -> 그래서 웹 API라는 것

 

예를 들어 소셜 네트워크에 사진과 글을 올리는 과정을 설명하는데,

소셜 네트워크 백엔드가 사진과 텍스트를 수신하면, 사진은 서버의 파일 시스템에 저장되고, 텍스트는 사진의 식별자와 함께 데이터베이스에 저장된다. 

하진을 저장하기 전에 직접 만들어 둔 얼굴 인식 알고리즘을 이용해 사진 속에 친구가 포함되어 있는지 확인할 수도 있다.

 

위 과정을 확장하면 애플리케이션 하나가 여러 독립된 애플리케이션을 다루는 상황도 상상해 볼 수 있다고 한다.

API를 통해 사진과 텍스트를 저장하고, sns 백엔드에서는 얼굴인식 API, 저장 API, 타임라인에 추가 API 등을 호출하여 작업이 이루어진다고 이해했다. 이런 과정이 레고와 같다고 한다.

API로 접근이 가능해 어디서든 실행 가능하니 동시에 여러 곳에서 사용 가능하며 이러한 점이 API의 성능과 확장성을 관리하는데 유리하다.  

 

API 디자인이 중요한 이유

API를 사용하는 consumer 입장에서 사용하기 쉬워야 하기 때문인 것이 내가 생각하는 첫 번째 이유인 듯하다.

외부 API를 사용하는 경우라면 누가 개발한 지 모른 채 사용하게 되는데 이때 사용에 어려움이 없어야 좋은 API라고 할 수 있기 때문이다. 

이러한 API를 사용하는 개발자의 경험을 Developer Experience라고 한다. 사용하기 유용하고 쉽도록 개발하는 것이 API 개발의 키라고 한다.

 

API는 구현을 숨긴다

API 내부가 어떻게 구현되는지 consumer는 알 필요가 없다.

음식점에서 음식을 주문하는 경우와 비교를 했는데, 우리가 음식점에 가서 음식을 주문할 때 요리가 어떻게 되는지는 알지 못하고 점원을 통해 음식 주문과 서빙을 받는다.

이 점이 API를 통해 상호작용하는 점과 비슷하다. API에게 요청한 결과가 구현되고 수행되는 것은 provider 애플리케이션에서 일어난다.

 

어설픈 API 디자인은 끔찍한 결과를 초래

형편없이 디자인된 제품들은 잘못 쓰이거나 제대로 쓰이지 않거나 아예 쓰이지 않는다. 사용자들에게만 위험한 것이 아니라 제품을 만든 조직에도 위험하다.

(내가 만든 API가 이런 상황.. ㅠㅠㅠ)

상황이 어찌 됐든 간에 API 디자인 결함은 이 API를 사용하는 소프트웨어가 들이는 시간과 노력과 비용을 증가시킨다,

그러므로 API를 적절하게 디자인하는 법을 학습하면 된다.


모든 API가 이해하기 쉽고 사용하기 쉽게 만들어져야 한다.

라는 것이 결론이며 내가 개발해왔던 API를 생각해보면 그때는 reasonable 하다고 생각했던 것들이 전혀 그렇지 않고 내가 놓치고 개발한 점들도 참 많다. 이제라도 다시 개발해 볼 생각을 한 것만으로도 기특하다고 해야 할까.. ㅎㅎ

728x90
반응형
728x90
반응형

사내 스터디 세미나로 준비한 자료 정리

 

Go 언어를 활용한 마이크로서비스 개발

2장 좋은 API 디자인하기


api 규약 작성이 매우 중요하며 어려움

RESTful API

  • REpresentational State Transfer(표현적 상태 전송)
    • 컴포넌트(서비스 단위) 간 상호작용의 확장성, 범용적인 인터페이스, 컴포넌트의 독립적인 배포를 강조하며 응답 지연시간 감소, 보안 강화, 레거시 시스템의 캡슐화를 위한 중간 컴포넌트 역시 강조한다.

URI, URN, URL

  • RFC 3986
  • URI 형식 지정의 규칙
    • 슬래시(/)는 리소스 사이의 계층적 관계를 나타내는 데 사용
    • URI의 마지막에 슬래시가 포함되어서는 안된다.
    • 하이픈(-) 사용, _ 사용 x
    • 대소문자 구분하므로 소문자 사용 권장

URI 경로

표현설명비고

GET /cats 모든 고양이 컬렉션 명사로 명명
GET /cats/1 1번 고양이를 위한 하나의 문서 db의 행과 비슷. 하위 리소스를 가질 수 있음
GET /cats/1/kittens 1번 고양이의 모든 새끼 고양이들  
POST /cats/1/feed 1번 고양이에게 먹이 주기 컨트롤러: 하위 경로가 없는 URI의 마지막 부분, 동사 사용
POST /cats/1/feed?food=fish 1번 고양이에게 물고기를 먹이로 주기 컨트롤러의 매개변수
PUT /cats/2 2번 고양이 추가(새로운 URI 생성이 아닌 리소스 추가 저장) 컬렉션과 마찬가지로 명사로 명명

REST URI 디자인

  • DELETE /cats/1234: 좋은 예
  • GET /deleteCat/1234: 나쁜 예
  • POST /cats/1234/delete: 나쁜 예
  • HTTP 동사
    • GET / POST / PUT / DELETE / PATCH / HEAD / OPTIONS

응답코드

  • 요청의 성공이나 실패를 클라이언트에게 알려주기 위한 HTTP 응답 코드
  • 즉각적으로 요청의 상태를 알 수 있게 설계

나쁜 응답

POST /kittens RESPOSNE HTTP 200 OK { "status": 401, "statusMessage": "Bad Request" }

POST /kittens RESPOSNE HTTP 200 OK { "id": "123434jvjv4564", "name": "Fat Freddy's Cat" }

  • 좋은 응답은 HTTP 상태 코드를 문자 그대로 사용하는 것

실패 응답의 좋은 예

POST /kittens RESPONSE HTTP 400 BAD REQUEST { "errorMessage": "Name should be between 1 and 256 characters...." }

성공한 응답의 좋은 예:

POST /kittens RESPONSE HTTP 201 CREATED { "id": "123434jvjv4564", "name": "Fat Freddy's Cat" }

HTTP 상태 코드

  • 구글에 더 자세하게 나와있지만 간략하게 정리
  • 200 OK: 요청이 성공했음을 나타내는 일반적인 응답 코드
  • 201 Created(생성): 요청이 성공하고 새 엔티티가 생성된 경우의 응답
  • 204 No Content: 내용 없음. 클라이언트의 요청이 잘 처리되었지만 본문은 없음. DELETE 요청에 대한 응답이 될 수 있음
  • 3xx: 경로 재지정.
  • 4xx: 클라이언트 에러
    • 400 Bad Request / 401 Unauthorized / 404 Not Found / ...
  • 5xx: 서버 오류

mozilla 상태코드 참고 사이트

HTTP 헤더

  • 표준에 맞추면 모두에게 도움이 된다!
  • 표준 요청 헤더
    • 요청에 대한 메타 데이터 개념
    • 요청 및 API 응답에 대한 추가 정보 제공
  • Authorization - 문자열
    • 권한 부여: Authorization key 요청
    • 이런 표준 접근 방식을 따르면 클라이언트가 알아서 구현알 수 있다는데
    • 사실 이걸 어떻게 부여하는지는 잘 모르겠습니다!
  • Date
    • 요청의 타임스탬프
  • Accept - 콘텐츠 타입
    • application/xml
    • text/xml
    • application/json
  • Accept-Encoding - gzip, release
    • REST 엔드 포인트는 가능한 경우 gzip과 deflate 인코딩을 항상 지원해야 한다.
    • gzip 지원은 간단함: 표준 라이브러리의 일부인 compress/gzip 패키지 사용
    • 뉴욕타임즈 오픈소스
    • 비손실 압축을 위한 인코딩,,
  • 에러 리턴
    • API 사용자는 에러가 발생했을 때 여러 앤드 포인트에서 발생한 에러를 처리하는 하나의 코드를 작성할 수 있어야 하는데
    • 표준 에러 엔티티를 제공함으로써 클라이언트 또는 서버로 인한 에러가 발생할 때 클라이언트를 도와줄 수 있음
    • 마이크로소프트의 API 가이드라인 자료

API 버전 관리

  • 초기부텉 고려해야하는 사항, 피할 수 있으면 피하는 것이 좋다!
  • 버전 관리가 필요한 상황
    • 주요 변경 사항이 생기면 API 버전 번호를 증가시키는데 주요 변경사항은
      1. API나 API 매개 변수의 제거 또는 이름 변경
      2. API 매개 변수의 타입 변경(정수 -> 문자열)
      3. 응답 코드, 에러 코드 또는 실패 규약 변경
      4. 기존 API 의 동작 변경
  • 시맨틱 버전 관리
    • 메이저 버전과 마이너 버전: 1.0 에서 1은 메이저, .0은 마이너
    • 마이너의 변경은 클라이언트가 API와 상호작용하는 데 영향을 주지 않음
  • REST API의 버전 관리 형식

객체 타입 표준화

  • 클라이언트에서 객체를 쉽게 처리할 수 있도록 고려
  • JSON을 사용하는 경우 기본 타입으로 날짜 개념이 없다! --> ISO 표준을 사용하는 것이 도움이 된다
    • {"date": "2021-07-08T04:52:57Z"}
    • {"date": {"kind": "U", "value": 1625719977221}

API 문서화

  1. Swagger
  • YAML로 작성
  • 배책임님께서 이전에 소개해주신 API 문서 자동화 도구!
  1. API Blueprint
  • 마크다우능로 작성돼 중첩된 레이어를 다루는 것보다 좀 더 자연스럽게 문서 작성 가능
  1. RAML
  • RESTful API Modeling Language의 약자
  • YAML로 작성

API 문서 자동화 오픈소스(https://github.com/swaggo/swag)

여러가지 참고 링크

728x90
반응형

+ Recent posts