API 모델링 및 개발

개발 2016. 8. 31. 18:22
APIs: Application Programming Interface
--------------------------------------

1. HTTP 
- **HTTP is request / response**
- HTTP  Primer
- URLs
- ![URLs](https://ed.fnal.gov/lincon/graphics/absolute_url.gif)
- protocol 
- host 
- port 
- resource path 
- query
- Header : key value
- Body : details
- HTTP Verbs
- GET : collection 이나 individual resource 획득, 생성에 관여해서는 안된다
- POST : 새로운 resource 생성
- PUT : 생성된 resource 에 대한 변경
- DELETE : 생성된 collection / resource 에 대한 삭제
- **PATCH** : PUT 과 유사하나 일부 속성을 변경할 때 주로 사용됨
- HTTP Response Code
- 2xx : SUCCESS에 관한 코드
- 200 : ok
- 201 : created
- 202 : accepted
- 204 : no content (주로 delete API 에 사용한다)
- 4xx : CLIENT_ERROR에 관한 코드 (요구 메시지가 처리할 수 없을 때)
- 400 : bad request
- 401 : unauthorized
- 403 : forbidden
- 404 : Not found
- 5xx : SERVER_ERROR에 관한 코드 (서버가 요청을 처리하는 과정에서 문제발생)
- 500 : Internal Server Error
- [reference](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html)

2. REST: REpresentational Statue Transfer
- 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식
- 특징
- Uniform Interface (Loose Coupling): 
- 아키텍처를 단순화시키고 작은 단위로 분리(decouple)함
- 클라이언트-서버의 각 파트가 독립적으로 개선 가능
- Client / Server 구조: 일관적인 인터페이스로 분리되어야 한다
- Stateless: 각 요청 간 Client 의 context 가 서버에 저장되어서는 안 된다 ( == 구현이 단순해진다 )
- Cacheable: WWW 에서와 같이 Client 는 response 을 caching 할 수 있어야 한다
- 클라이언트-서버 간 상호작용을 부분적으로 또는 완전하게 제거하여 scalability 및 성능 향상
- Layered System: Client 는 REST API 서버만 호출한다
- Server 내부에 다중 계층을 구성하여 로드 밸런싱, 공유 캐시, 인증, 비즈니스 을 나누어 관리할 수 있다
- --------------------------------------------
- Code on demand (optional): 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다

- 고려사항
- **transcation: 연속적 API 호출에 대한 트랜잭션을 보장하지 않는다**
- **Idempotent**
- API 호출 실패에 대한 구체적인 명시가 필요하다
- 필요의 경우, 보상 트랜잭션의 구현이 필요하다
- **실패에 대한 처리: 예외코드 / 예외메시지 를 제공한다**
- client 의 조치가 필요한 케이스
- retry / restart 등의 조치
- server 의 조치가 필요한 케이스

3. API 모델링 및 디자인
- API 모델링 steps
- step1 : Identify participants
- 사용할 object 단위로 정의해라? 
ex) system admin, customer, manager etc ...
- step2 :  Identify Activities
- object 들의 동작과 동작결과를 정의해라? : 한줄정도 요약
- step3 : Break Into Steps
- 동작을 쪼개어 순서대로 정의해라 : 요약된 한줄의 동작을 수행하는 단계를 정의
- step4 : Create Resource API Definitions
- 각 단계 에서 필요한 items 들을 정의해라
- 힌트 :
- 일반적인 개념과 같은 그룹
- db 테이블에서 사용하는 properties 가 될 수 있다
- step5 : Validate API
- API 디자인 steps
- step1. Ontology 구성
- 클래스(class), 인스턴스(instance), 관계(relation), 속성(property)
- step2. 구성원들간의 관계 정의
- Independent : 독립적으로 존재
- Dependent: 부모 resource 의 존재에 의해 생성 가능한 존재
- Associative: 독립적인 존재이지만, ...
- step3. HTTP 규격에 맞게 정의하기
- method: CRUD
- URL: 구성원
- response: API 수행결과
- step4. 프로토 타입 공유
- 실습

story : As a customer, I want to order a coffee so that the coffee shop can prepare my drick

1. modeling exercise

- step1 : Identify participants

Customer, waitress, Barista 

- step2 :  Identify Activities

Order | Customer, waitress |

Prepare Coffee | Barista | 

- step3 : Break Into Steps

Order

Select Menu | Customer

Order | Customer

Confirm Order | Customer, waitress

Prepare Coffee

Confirm Order | Barista

Make Coffee | Barista

- step4 : Find Resources

Order

menu list,  menu detail

Make Coffee

ingredient

- step5 : Validate API

Order

- Select menu list API | Customer, waitress

- Create Order API | waitress

- Confirm Order API | Customer, waitress

Make Coffee

- Get Order API | Barista

- Make Coffee | Barista

2. design exercise

Order

- Select menu list API

GET /menu | 200 OK , 500 Internal Server Error

- Create Order API

POST /order | 201 Created , 204 No Content , 400 Bad Request , 500 Internal Server Error

- Confirm Order API

POST /order/{order_id} | 200 OK , 500 Internal Server Error

Make Coffee

- Confirm Order API

GET /order/{order_id} | 200 OK , 404 Not Found , 500 Internal Server Error

- Make Coffee

POST /coffee/ | 201 Created , 204 No Content , 500 Internal Server Error 

4. 훌륭한 API 의 7가지 특징
- #1. Greate APIs "Just Work": 직관적이고 예측 가능해야한다
- #2. Greate APIs are Interactive (대화)
- Documentation is great
- Interactive documentation is better (like JAVA DOC) >> swagger 가 유용하다
- #3. Greate APIs have Examples
- should be short
- something useful
- simple and complex use case
- #4. Greate APIs are Considerate 신중한, 주의 깊은
- protocol 과 payload 를 쉽게 사용할 수 있도록 선택해야 한다 
- ex) REST vs SOAP, JSON vs XML 
- [REST와 SOAP비교] (http://greatkim91.tistory.com/79)
- #5. Greate APIs are Adoptable 채용
- 쉽게 호할 수 있도록
- high value for 비즈니스
- low pain for 통합/유지보수
- #6. Greate APIs offer Variation in Granularity
- 3 레벨
- access APIs ( row한 의 API )
- workflow APIs ( 상위레벨의 API )
- SDK APIs ( 개발 언어별로 )
- #7. Greate APIs are Consistent
- name, design, error handle, massage


'개발' 카테고리의 다른 글

Ubuntu 머신에서 다른 머신 제어하기  (0) 2016.09.09
Ubuntu 설치 후 초기 환경 세팅  (0) 2016.09.07
RabbitMQ 사용하기-2  (0) 2016.09.06
RabbitMQ 사용하기-1  (0) 2016.09.05
API 모델링 및 개발 - 2  (0) 2016.09.01
Posted by 감각적신사
,