[19일차] 복습(데이터베이스, API)

 

데이터 베이스 종류

 

• Oracle
  • 미국 오라클(Oracle) 사의 관계형 데이터베이스 관리 시스템(RDBMS)
  • 오픈 소스 DBMS가 있음에도 안정성과 유지보수를 보장받을 수 있다는 장점 때문에 비 IT업종 기업에서 많이 사용한다.
  • 기업용으로 주로 사용
  • 대량의 정보관리를 할 때 타 DBMS에 비해 좋은 성능을 보인다.
  • 오라클 자체 SQL 쿼리를 사용해 표준 형식과 약간 다름

 

• MySql
  • 관계형 데이터베이스 관리 시스템(RDMS)
  • 오픈 소스이며, 다중 사용자와 다중 스레드 지원
  • 오픈 소스 라이선스를 따르기 때문에 무료로 사용 가능
  • 표준 SQL 형식 사용
  • 오픈 소스이기 때문에 기술 지원의 한계가 있음

 

• MS-SQL
  • 미국 마이크로스프트에서 개발한 관계형 데이터베이스 관리 시스템(RDBMS)\
  • 분산된 기업환경에서의 집중된 서버 관리 도구 제공
  • 데이터베이스 관리 시스템 툴인 MS-SQL 서버 관리 스튜디오의 사용이 매우 편리함
  • 마이크로소프트 개발이다 보니 모든 버전의 Windows에서 문제없이 잘 작동됨
  • 중앙 집중식 테이버 베이스 제어로 통신 누락, 오류 발생 최소화
  • .Net 언어 구현에만 초점을 맞춰 설계됨

 

• PostrgreSQL
  • 오픈 소스 객체-관계형 데이터베이스 시스템 (ORDBMS)
  • macOS 서버의 경우 기본 데이터베이스로 사용된다.
  • 초기 개발 단계부터 완벽한 ACID와 MVCC를 지원하는 아키텍처로 설계
  • 다양한 데이터베이스 객체를 사용자가 임의로 만들 수 있는 기능을 SQL 차원에서 제공
  • 테이블 상속 기능을 이용해 하위 테이블 생성 가능
  • 오픈 소스임에도 상용 RDBMS급의 기능을 제공
  • 기본적인 CRUD 성능이 경쟁 DB에 비해 좋지 않다.

 

• MongoDB
  • 크로스 플랫폼 도큐먼트 지향 데이터베이스 시스템
  • NoSQL 데이터베이스
  • ACID 대신 BASE를 택해 성능과 가용성을 우선시함
  • 모든 데이터가 JSON 형태로 저장, 스키마가 없음
  • 다양한 인덱싱 제공
  • 일관성이 매우 중요한 작업에는 사용하기 힘들다

 

• Redis
  • Remote Dictionary Server의 약자
  • Key-Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비 관계형 데이터베이스 관리 시스템
  • 모든 데이터를 메모리로 불러와서 처리하는 메모리 기반 DBMS
  • 메모리 기반이기에 속도가 빠르고 간편
  • 최고의 성능이 필요한 웹, 모바일, 게임, 광고 기술 및 IoT 애플리케이션에서 널리 사용
  • 문자열, 리스트, 해시, 셋, 정렬된 셋과 같은 다양한 자료구조의 지원

 

•  MariaDB
  • 오픈 소스의 관계형 데이터베이스 관리 시스템(RDBMS)
  • MySQL과 동일한 소스 코드를 기반, GPL v2 라이선스를 따름
  • MySQL의 개발진들이 오라클의 정책이 추구하는 바와 맞지 않아 나와서 개발한 DB
  • MySQL이 오라클에 인수되면서 만들어진 오픈소스 RDBMS
  • 위의 말한 관계로 인해 MySQL과 거의 100% 호환성을 가지고 있음
  • MySQL에 비해 애플리케이션 부분 속도가 약 4~5천 배 빠르고, 성능면에선 70% 향상을 보인다고 말함
  • 좀 더 자유로운 MySQL 정도로 이해하면 될듯함
  • 라이센스와 오라클로부터 자유로움
  • api 만들기 정리

 

 

서버 정리

Web Server

• 웹브라우저(클라이언트)로부터 요청을 받아 정적인 콘텐츠(html, css, jpeg)를 처리하는 시스템
• 종류 : Apache, Nginx, IIS

 

 WAS (Web Application Server)

• DB 조회나 다양한 로직을 처리를 하는 동적인 콘텐츠를 처리하는 시스템
• 종류 : Tomcat, Jeus, JBoss
• 사용 언어 : PHP, JSP, ASP

 

DB

• DataBase의 약자로 데이터 집합 또는 저장소
• 종류 : MySQL, Oracle, MongoDB 등
• DB 테이블 : 시스템에서 데이터가 저장되는 형태로 데이터의 종류와 형식을 확인 가능함. 보
• 컬럼(Column) : DB테이블의 열로 같은 종류로 묶인 항목 (예시 : 번호, 이름, 반, 점수)
• 레코드(Record) : DB테이블의 행으로 항목이 1개씩 포함된 데이터 묶음
• 쿼리(Query) :DB에 정보를 조회 요청하는 것
• SQL (Structured Query Language) : 관계형 DB에 정보를 관리(등록/삭제/변경/조회)하기 위한 언어
• nsert : 등록    update : 변경   delete : 삭제   select : 조회
• 쿼리는 DB에 정보 조회를 요청하는 행위이며 SQL를 이용하여 DB에서 select하여 DB 조회 명령을 할 수 있다.
• 쿼리 요청시 web, was가 실행되고 있어야 한다.

출처: https://www.stevenjlee.net/2020/05/08/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3%EA%B3%84%EC%B8%B5-%EA%B5%AC%EC%A1%B0-3-tier-architecture/

 

API

• RESTFUL API의 3요소

구성 요소	내용	표현 방법	예
자원(Resource)	자원	HTTP URI	/members/{1}, /member/
행위(Verb)	자원에 대한 행위	HTTP Method	POST, GET, DELETE, PUT
표현(Representations)	자원에 대한 행위의 내용 (즉, 요청에 대한 Body)	HTTP Message Payload (JSON, XML, TEXT, RSS 등)	{  member-id:”82370”,  member-name:”홍길동“,  member-org:”10100”,  member-location:”11010” }

 

• 서브 URL 표현식을 통해 세부 표현
•  API내부에 다른 리소스와 관계가 있을때 서브 리소스 표현으로 그 관계를 표현한다

METHOD	API	DESC.
GET	/cars/711/drivers/	711번 id를 사용하는 car의 드라이버 리스트를 반환
GET	/cars/711/drivers/4	711번 id를 사용하는 car의 드라이버 중 드라이버 id가 4번인 드라이버를 반환
POST	/tickets/12/messages	ticket 넘버 12번에 새로운 메시지 생성
PUT	/tickets/12/messages	tcket 넘버 12번에 메시지 5번을 업데이트
PATCH	/tickets/12/messages/5	ticket 넘버 12번에 메시지 5번을 부분적으로 업데이트
DELETE	/tickets/12/messages/5	ticket 넘버 12번에 5번 메시지 삭제

 

 

상태 코드 설명

• Sorting: 예를들어 클라이언트가 정렬된 회사 목록을 가져오려는 경우 다음의 예처럼 처리
• ex) GET /companies?sort=rank_asc

 

• Filtering: 데이터셋의 데이터를 필터링 할 때, 다양한 쿼리 파라미터를 통해 필터링 처리 가능
• ex) GET /companies?category=banking&location=india
• (컴퍼니의 카테고리를 은행으로 정하고 은행이 위치한 장소를 인도로 필터 처리)

 

• Searching: 검색은 다음의 예제와 같이 표현
• ex) GET /companies?search=Digital

 

• Pagination: 페이징 처리 예제
• ex) GET /companies?page=23

 

REST의 중요성

• REST를 실행하는 기본적인 목적 중 하나는 URI 체계에 대해 미리 알고 있지 않아도 전체 리소스 집합을 탐색할 수 있기 때문이다.
• 각 HTTP GET 요청은 응답에 포함된 하이퍼링크를 통해 요청된 개체와 직접 관련된 리소스를 찾는 데 필요한 정보를 반환해야 하며, 이러한 각 리소스에 대해 사용할 수 있는 작업을 설명하는 정보도 제공되어야 한다.
• 이 원칙을 HATEOAS(Hypertext as the Engine of Application State)라 한다.
• 시스템은 실질적으로 상태 시스템으로서, 각 요청에 대한 응답은 한 상태에서 다른 상태로 바꾸는 데 필요한 정보를 포함하고 있으며, 다른 정보는 필요하지 않다.

• 이 응답에는 사람의 이름뿐만 아니라 그 사람의 이름으로 참조해야 하는 관계된 URL까지 링크로 제공해 주고 있다
• rel은 관계를 의미. 이 예제에서 사용한 'self'라는 의미는 같은 웹 사이트를 사용하는 참조 하이퍼링크라는 뜻이다
• href는 리소스를 고유하게 정의하는 완전한 URL이다
• HTTP 메서드 및 지원되는 MIME 형식이 포함됨. 이 모든 정보가 있어야 클라이언트 애플리케이션이 작업을 호출할 수 있다

 

• JSON을 통한 에러 응답 처리
  •  API는 항상 자체 필드 집합에서 오류 메시지를 반환하도록 적극 권장한다
  • JSON 오류 본문은 개발자에게 유용한 오류 메시지, 고유한 오류 코드(문서등을 통해 자세한 내용을 찾을 수 있게해야 함) 및 가능한 자세한 설명 등 몇 가지 사항을 제공한다

{ "코드": 1234, "message" : " 오류가 발생했습니다 .", "description" : "오류에 대한 자세한 내용은 xxxx를 참조." }

 

• RESTful API 작성 예시
  • URI는 리소스 식별이 유추 될 수 있도록 작성되어야 한다
  • http(s)://{Domain name (:Port #)}/{A value indicating REST API}/{API version}/{path for identifying a resource}
  • http(s)://{Domain name indicating REST API(:Port #)}/{API version}/{path for identifying a resource}
  • http://example.com/api/v1/members/M000000001
  • http://api.example.com/v1/members/M000000001

 

• path는 내가 무엇을 원하는지를 직관적으로 보여줄 수 있게 작성해야 한다
• “ 사용자는 모든 상품을 조회할 수 있다 ”일 경우
  • - PATH : /products/를 활용한다
  • - 복수형으로 작성하는게 좋다
  • “ 사용자는 특정 분류의 상품을 조회할 수 있다(상품분류, 브랜드명, 가격, 상품명)”
  • - PATH :
  • /products?categories=${categotrid}&brand=${brandid}&price=${price}&productname=${productname}
  • - 이럴경우 path를 여러개로 나눌건지(로직을 나눌건지) 한번에 생성할것인지 고민 필요
  •  - 한번에 할 경우 로직이 복잡해져 백엔드에서 수고스러워진다 
  • - api는 한번 만들면 변경할 수 없으므로 신중하게 작성해야 함

 

• 실제로 코드 상에서 날아가는 실제 요청은 " curl GET주소/api/product cotent " 이다
  • GET은 굳이 REQ가 필요없다, 받을것만 받으면되고 GET에는 바디를 안넣는다
  • POST에서 무엇을 받을것인지 쓰고, 원하는 값을 설정하면 된다
  • 데이터를 생성하는 것이기 때문에 요청시에 Body 값과 Content-Type 값을 작성해야한다.
  • URL을 통해서 데이터를 받지 않고, Body 값을 통해서 받는다.
  • 데이터 조회에 성공한다면 Body 값에 저장한 데이터 값을 저장하여 성공 응답을 보낸다.
  • 유저가 누군지 정도는 헤더에 놓고 세부사항까지는 바디에 놓는다

 

=====================================

참고 자료

https://bcho.tistory.com/

조대협의 블로그