1. API 설계의 안티패턴

- GET-POST 를 이용한 터널링

- method=update 와 같은 파라미터 쿼리를 이요한 데이터 조작

- 복잡한 파라미터와 구조로 직관성 결여, 재활용성 저하

- HTTP Response code 미사용


2. API 설계 원칙

- URI 의 단순화

- api model 의 class 로 구성: /car

- 행위에 대한 정의는 좋지 않다: /getCar

- resource 간의 관계

- sub resource 표현: /user/{userID}/car/{carID}

- sub resource 간의 관계: /user/{userID}/wish/car/{carID}

- 예외-응답 코드 사용

- API 버전 관리: 

- URL: /api/v1/user , /api/v2/user

- 파라미터: /api/user?version=1 , /api/user?version=2

- 해더: "Accept-Version: 1.0" , "Accept-Version: 2.0"

- HTTP 매서드 재정의


3. API 개발 절차


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

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

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 감각적신사
,

MySQL , MariaDB

Database 2016. 8. 30. 13:07

# MySQL , MariaDB

------------------

[mysql공식](dev.mysql.com)

[MariaDB](mariadb.org)

[mariadb installation](http://www.tutorialbook.co.kr/entry/Ubuntu-1404LTS-%EC%97%90-MariaDB-10-%EB%A5%BC-apt%EB%A1%9C-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0)


0. MySQL

- deafult : InnoDB 엔진

- 5.6 버전 이후 권장


1. MariaDB

- Mysql 과 동일하다, 커멘드 기타 등등

- deafult : InnoDB 엔진

- XtraDB엔진 : InnoDB 엔진의 강화버전 , Mysql 과 차별화 되는 점(아직 사용사례가 없다)

- open source 로 mysql 에 더 많은 기능을 추가하고자 한다

- cassandra 와 친해지려 한다

- 10.0 버전 이후 권장


2. MariaDB vs Mysql

- 엔진 비교

- InnoDB 

- 트랜잭션 보장 엔진

  - 확장성, 성능, 모니터링 일부 미흡 

- 원하는 테이블에 대해서만 MyISAM 엔진을 사용할 수 있도록 옵션을 주어 설정할 수 있다

- MyISAM 

- 트랜잭션 미보장 엔진 (배치성으로 작업하는 DB) 

  - 기능과 구조가 단순한 스키마에 적합하며 빠른 성능을 보장한다

- Aria 엔진 

- MyISAM 엔진의 강화버전(트랜잭션부분 일부 지원), 

- MyISAM 엔진 대비 강점 

1. crash safe : (myisam 대비, aria-log.xxxx 파일을 생성하여 메모리에서 발생한 정보를 기록한다) 

2. caching : data + index (myisam 은 index 만 캐싱이 가능하다)

- 튜닝 포인트 : aria-pagecache-buffer-size 

3. 트랜잭션 일부 지원

- 튜닝 포인트 : aria-checkpoint-interval  ... : wal file 의 주기 

- 기능 비교

        

- buffer pool 의 프리 로드 (온/오프가 가능하다)

- 자주 사용하는 정보는 메모리에 올린다

- 서브쿼리 최적화 : Oracle 은 기본으로 기능 제공 (왠만하면 안쓰는 것을 추천함)

- 마리아 DB 는 from 절의 서브쿼리만...


3. 모니터링을 위한 커멘드 (Mysql, MariaDB 공통)

- show processlist :  mysql 의 현재 쓰레드 별 상태 정보를 보여주는 명령어

- info 컬럼의 경우 전체 명령어가 나오지는 않는다 <-> oracle 은 전문 출력이 가능하다

- show status : mysql 의 통계정보를 모니터링 하는 명령어

- copy to tmp table : alter table 문을 수행중 데이터는 옮겨지기 전

- copying to group table : oder by , group by 절의 컬럼이 다를때 

- sorting for group

- sorting for order

- executing : 

- sending data : 쿼리문 결과를 주는 작업

- killed

- locked

- show slave status : replication 을 모니터링 하기 위한 slave 서버에서 수행

- seconds_behind_master: sec 단위의 벌어진 격차를 기록, 갭이 늘어나면 문제


4. 서버 프로세스 (Mysql, MariaDB 공통)

  

- Connection layer : 커낵션 핸들링

- communication protocols : 

- TCP/IP

- Unix socket file

- Shared memory

-Named pipes

- threads

- 커넥샨당 하나의 thread 유지

-쿼리 실행을 핸들링

- Authentication

- id/pw 점검

- SQL layer

- Parser : 문법 검사

- Authorization : 유저 권한 확인

- Optimizer : 쿼리에 대한 실행 계획 생성

- Query execution : 실행계획에 따른 쿼리 수행

- Query cache : SQL 문과 수행결과를 메모리에 캐싱

- 용도코드성에 쓰는게 좋다 (대부분 0 으로 튜닝한다)

- 일반적인 OLTP 시스템에서는 적절하지 않다

- Query logging : 실행 쿼리 기록

- Storage layer

- Disk : 디스크 상에 데이터를 저장하는 스토리지 엔진

- InnoDB

- MyISAM

- Memory : 메모리 상에서 데이터를 저장하는 스토리지 엔진 

- Network : 데이터 고가용성을 위해 클러스터를 활용한 확장

- Network Block Device


5. Disk 공간의 사용 (Mysql, MariaDB 공통)

- MAD, MAI, etc


6. Memory (Mysql, MariaDB 공통)

- Server/Shared : Query cache, Thread cache

- Storage Engine/Shared : 

- buffer pool : 전체 메모리의 50 ~ 80% 로 설정하는 것이 좋다

- 튜닝시, DB 가 죽지 않게는 해줄수 있다 

- default 300 MB

- log buffer : InnoDB 의 경우

- key buffer : MyISAM 의 경우 index 만 캐싱하고 데이터는 하지 않는다

- Connection/Session : Sort buffer, Read buffer, Temporary table(sort 하기 위한 임시 테이블)


7. HA (Mysql, MariaDB 공통)

- replication

 ----------------- ( 아래는 상용 솔루션 이다 ) ----------------- 

- MHA

- MHA manager : master 를 heart-bit 하다가 slave 를 올린다(마스터로 ), 

               auto fail0ver 는 되는데 auto filaback 은 안된다

- DRBD

- auto fail0ver 는 되는데 auto failaback 은 된다

- 4 TB 이상은 지원하지 않는다

- 트랜잭션 지원 디비 엔진(Inno, Xtra)만 지원한다

- OS Cluster

- Galera

Posted by 감각적신사
,