Karice의 여행 & 코딩 블로그

정의 : 

Hypermedia As The Engine Of Application State의 약자로 REST 아키텍처의 한 구성 요소이다.

HATEOAS를 통해서 애플리케이션의 상태를 전이할 수 있는 메커니즘을 제공할 수 있다.

API에서 리소스에 대해 어떠한 행동을 할 수 있는지 URL을 전달하여 클라이언트가 참고하고 사용할수 있도록 한다.

이때 해당 리소스의 상태에 따라 링크 정보가 바뀌며 동적으로 리소스를 구성한다.

REST API가 무엇인가?

REST API는 Representational State Transfer API의 약자로,

“웹 애플리케이션이 제공하는 각각의 데이터를 리소스, 즉 자원으로 간주하고 각각의 자원에 고유한 URI(Uniform Resource Identifier)를 할당함으로써 이를 표현하는 API를 정의하기 위한 소프트웨어 아키텍처 스타일이다.

예시 : 

송금 어플리케이션이 현재 Home 화면을 나타내는 상태에 있다고 생각해 봅시다. 이 Home 화면에는 입금, 출금, 송금 등 다른 화면 혹은 기능, 리소스로 갈 수 있는 링크들이 존재할 것입니다. 이 링크를 통해서 다른 페이지로 가는 것을 다른 상태로 전이한다고 보고 이 링크들에 대한 레퍼런스를 서버 측에서 전송합니다. 그럼으로서 클라이언트가 명시적으로 링크를 작성하지 않고도 서버 측에서 받은 링크의 레퍼런스를 통해 어플리케이션의 상태 및 전이를 표현할 수 있습니다. 이것이 바로 올바른 REST 아키텍처에서의 HATEOAS 구성법입니다.

결과값 : 

참고 : 

https://joomn11.tistory.com/26

https://engkimbs.tistory.com/866

https://brunch.co.kr/@purpledev/29

https://sabarada.tistory.com/31

정적 웹페이지

항상 같은 내용을 보여주는 웹페이지를 뜻합니다.

특징 :

• 글 자체가 전부 HTML 단위의 파일들로 이루어져 있습니다.
• DB 사용 X
• 동적인 요소가 없기 때문에 데이터베이스 등이 필요없고, 구축이 쉬움.
• 단순 문서로만 이루어져 있어서 서버간 통신이 거의 없고 속도가 빠름.
• 정적인 문서들로만 이루어져 있기 때문에 어떤 호스팅 서버에서도 동작 가능.
• 일반 텍스트 에디터기에서 문서를 작성이 가능. 즉, 익숙한 에디터기를 사용할 수 있음.
• 백업, 복원이 쉬움.
• 클라이언트 사이드 렌더링
• 블로그 등의 예시가 있음

동적웹페이지

이름 그대로 사용자의 활동에 따라 웹페이지가 바뀌어가는 웹페이지를 뜻합니다. (ex. 네이버 홈)

특징 : 

• DB & 웹 애플리케이션 서버가 필요
• 서버사이드 렌더링
• 사용자의 인터렉션에 따라 웹페이지가 달라짐
• 게시판이나 홈페이지들이 보통 여기에 해당함

참고 : 

https://snowdeer.github.io/blog/2016/03/21/static-dynamic-webpage/

https://engineering.linecorp.com/ko/blog/how-to-quickly-develop-static-pages-in-line/

정의 : 

애플리케이션을 인터넷에 올려놓아 다른 사람들도 볼 수있게 해주는 것을 말한다.

방법 : 

1. 내 컴퓨터 자체를 서버로 만드는 방법

- 내 컴퓨터 자체를 서버로 만들어서 인터넷에 내 IP 주소를 알리는 방법

- 개인 컴퓨터를 공개하는 것이여서 보안에 취약, 컴퓨터를 24시간 가동해야됨

2. 외부 전문 서버를 이용하는 방법

- 영화에서 보는 것처럼 서버를 가지고 있는 회사에서 운영해줌

- 유지 비용이 상대적으로 적음

웹 호스팅 & 클라우드 서버

기업이 서버를 제공하는 것을 웹 호스팅 or  클라우드 서버라고 부른다.

유료 서비스도 있고, 무료 서비스도 있다.

ex) AWS(아마존) , Netlify(무료)

참고 : 

http://yoonbumtae.com/?p=3519 

https://developerdk.tistory.com/32

서론 : 

DBMS에 따라 처리단위가 다르다 (ex. Oracle - Block단위 , MySQL - Page 단위)

page가 클수록 효율적인 것은 아님, 적절한 Size가 제일 좋음

정의 : 

Index는 목차이며, data를 찾을때 처음부터 끝까지 확인하는 것을 방지해 준다.

추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색속도를 향상시킬 수 있다.

장단점 : 

장점

• 테이블을 조회하는 속도와 그에 따른 성능을 향상시킬 수 있다.
• 전반적인 시스템의 부하를 줄일 수 있다.

단점

• 인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장공간이 필요하다.
• 인덱스를 관리하기 위해 추가 작업이 필요하다.
• 인덱스를 잘못 사용할 경우 오히려 성능이 저하되는 역효과가 발생할 수 있다.

자료구조 종류

1. 해시 테이블(Hash Table)

(Key, Value)로 데이터를 저장하는 자료구조, 빠른 데이터 검색이 필요할때 유용하다.

Key값을 이용해 고유한 index를 생성하고 그것을 활용한다.

시간 복잡도는 O(1)

2. B+ Tree

 자식 노드가 2개 이상인 B Tree를 업그레이드 시킨 자료구조이다.

• 리프노드(데이터노드)만 인덱스와 함께 데이터(Value)를 가지고 있고, 나머지 노드(인덱스노드)들은 데이터를 위한 인덱스(Key)만을 갖는다.
• 리프노드들은 LinkedList로 연결되어 있다.
• 데이터 노드 크기는 인덱스 노드의 크기와 같지 않아도 된다.

O(logn)의 시간복잡도를 가지지만 해시테이블보다 인덱싱에 더욱 적합하다.

참고 : 

https://jeong-pro.tistory.com/114

https://mangkyu.tistory.com/96

https://chartworld.tistory.com/18

https://jungwoong.tistory.com/34

정의 :

개발자가 REST API 서비스를 설계, 빌드, 문서화할 수 있도록 하는 프로젝트이다.

활용 : 

1. 다른 개발팀과 협업을 할 경우

2. 이미 구축되어있는 프로젝트에 대한 유지보수를 하는 경우

3. 백엔드의 API를 호출하는 프론ㅌ엔드 프로그램을 제작할 경우

기능 : 

API 디자인, 빌드, 문서화, 테스팅, 표준화

적용 : 

pom.xml에 의존성 추가

  <dependencies>
       <!-- Swagger -->
       <dependency>
           <groupId>io.springfox</groupId>
           <artifactId>springfox-swagger2</artifactId>
           <version>2.9.1</version>
       </dependency>
       <dependency>
           <groupId>io.springfox</groupId>
           <artifactId>springfox-swagger-ui</artifactId>
           <version>2.9.1</version>
       </dependency>
   </dependencies>

컨트롤러 : 

• @Api
  • 해당클래스가 Swagger 리소스라는 것을 명시한다
  • value
    • 태그를 작성한다.
  • tags
    • 사용하여 여러 개의 태그를 정의할 수도 있다.
• @ApiOperation
  • 한 개의 operation(즉 API URL과 Method)을 선언한다
  • value
    • API에 대한 간략한 설명(제목같은 느낌으로)을 작성한다
  • notes
    • 더 자세한 설명을 작성해준다.
• @ApiParam
  • operation의 가능한 reponse를 명시한다.
  • code
    • 응답모드를 작성한다.
  • message -응답에 대한 설명을 작성한다.
  • responseHeaders
    • 헤더를 추가할 수 있다.
• @ApiParam
  • 파라미터에 대한 정보를 명시한다.
  • value
    • 파라미터 정보를 작성한다.
  • required
    • 필수 파라미터이면 true, 아니면 false를 작성한다.
  • example
    • 테스트를 할 때 보여줄 예시를 작성한다.

참고 : 
https://sarc.io/index.php/development/1974-swagger

https://doozi316.github.io/web/2020/10/16/WEB29/

https://jjingho.tistory.com/8

https://jojoldu.tistory.com/31

1. Python Filter 활용하기

활용 : 리스트에서 None 값을 제거하고 싶을떄

기존에는 For문을 돌려서 None일때 remove를 해줬는데, 이렇게 되면 가끔 안지워지는 것도 있고, 깨끗한 코드가 아니였다.

sample_list = ['', 'a', '', 'abc', 'qdsf']
sample_list = list(filter(None, sample_list))
sample_list # ['a', 'abc', 'qdsf']

이렇게 Filter를 None 빼주는 것으로 처리해주면, 다 없어진다.

좀더 찾아보니 이렇게도 가능한데, 내머리로는 아직 생각하기 힘든듯

sample_list = ['', 'a', '', 'abc', 'qdsf']
sample_list = [v for v in sample_list if v]
sample_list # ['a', 'abc', 'qdsf']

2. Python List와 String

문제 상황 : 밑에 사진처럼 결과값이 여러개 받을떄, js에서 배열로 넘겨줘서 방아서 True, False를 판단해주려고 했다.

그래서 Postman에서 어떻게 보내야 되나 고민하고 있었는데, 그냥 String -> List만 할줄알면되었다.

그것도 모르고 문제해결할때 1,0,0,0,0,0 이렇게 보내주고, split으로 잘라서 list를 만들었다.

해결 :

str = 'Hello world!'
list = list(str)

print(str)
print(list)

#결과값 
Hello world!
['H', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd', '!']

만약에 숫자로 바꿔주려면 list(map(int, list(str)))를 넣어주면된다.

3. Git 협업

얼마전에 이런 상황이 있었다.

1. 내가 먼저 main에서 branch A를 파서 코드를 짜고 있었다.

2. 다른 팀원이 main을 수정했다.

3. 나는 그걸 모르고, branch A를 merge하였다.

4. 어떻게 된지는 모르겠는데 main이 두개가 되고, 이전에 팀원이 수정한 main, branch A가 나온 main 두개가 되었다.

이런 경우는 어떻게 해야될까?

git pull로 main을 계속 업데이트 해줘야한다.

아니면 

git reset --hard origin/main --> main으로 모든 파일을 하드리셋한다.

정의

SOAP

SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다.

REST

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다

SOAP (Simple Object Access Protocol)

웹서비스 내의 모든 데이터는 XML로 표현된다.

그 데이터들과 이를 다룰 수 있는 오퍼레이션들이 WSDL로 정의되면 UDDI라는 전역적 서비스 저장 소에 등록(publish)되어 누구라도 서비스를 찾을 수 있도록 공개된다.

공개된 웹서비스가 이용될 때, 서비스 요청자와 서비스 제공자 간에 SOAP을 이용하 여 서비스를 호출하고 결과를 돌려받게 된다.  

SOAP 메시지는 아래 그림과 같이 SOAP 봉투(envelope), SOAP 헤더(header), SOAP 바디(body)로 구성된 하나의 XML 문서로 표현되는 데 이러한 복잡한 구성으로 인해 HTTP 상에서 전 달되기 무겁고, 메시지 인코딩/디코딩 과정 등 웹 서비스 개발의 난이도가 높아 개발 환경의 지원이 필요하다.

WSDL 용어는 XML이라고 보면 되고, UDDI는 일종의 검색 엔진이라고 보면 된다.

WSDL, UDDI는 웹 표준이기에 너무 복잡하게 생각하지 않아도 된다.

++ 추가 정보

SOAP는 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜입니다. 프로토콜이기 때문에 복잡성과 오버헤드를 증가시키는 빌트인 룰을 적용하므로, 페이지 로드 시간이 길어질 수 있습니다. 그러나 이러한 표준은 빌트인 컴플라이언스를 제공한다는 의미이므로, 기업에서 선호하는 방식이기도 합니다. 빌트인 컴플라이언스 표준에는 보안과 안정적인 데이터베이스 트랜잭션의 기본 속성인 원자성, 일관성, 격리성, 내구성(Atomicity, Consistency, Isolation and Durability, ACID)이 포함됩니다.

REST

REST는 HTTP 프로토콜로 데이터를 전달하는 프레임워크이다. 또 한 클라이언트/서버 간의 구성요소를 엄격히 분리하여 구현은 단순화시키고 확장성과 성능은 높일 수 있는 아키텍처다. 

여기서 리소스 (resource)란 REST 아키텍처의 핵심 요소로서 웹 사이트, 블로그, 이미지, 음악, 이용자, 지도, 검색 결 과 등 웹에서 다른 이들과 공유하고자 개방된 모든 자원을 의미한다. 

REST 구조에서의 리소스는 그들 의 고유한 URI를 가지며, HTTP의 기본 메소드인 GET/PUT/POST/DELETE만으로 접근할 수 있다. 

HTML, XML, 일반 텍스트, JSON과 같은 다양한 형식으로 메시지를 반환할 수있습니다

RESTful 애플리케이션 필요요소

1. 클라이언트, 서버, 리소스로 구성된 클라이언트-서버 아키텍처가 필요합니다.
2. 요청이 통과하는 서버에 클라이언트 콘텐츠가 저장되지 않는 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션이 필요합니다. 대신 세션의 상태에 대한 정보가 클라이언트에 저장됩니다.
3. 일부 클라이언트-서버 간 상호 작용의 필요성을 제거할 캐시 가능 데이터가 필요합니다.
4. 애플리케이션 요구 사항별로 다른 형식이 아닌, 표준화된 형식으로 정보를 전송할 수 있도록 구성 요소 간 통합된 인터페이스가 필요합니다. REST를 처음으로 제시한 Roy Fielding은 이를 "REST 아키텍처 스타일을 다른 네트워크 기반 스타일과 차별화하는 핵심적인 기능"이라고 설명합니다.
5. 클라이언트-서버 간의 상호 작용을 계층적으로 조정할 수 있도록 계층화된 시스템 제약이 필요합니다.
6. 실행 가능한 코드를 전송해 서버가 클라이언트의 기능을 확장할 수 있게 해주는 코드 온디맨드가 필요합니다. 단, 가시성이 감소할 수 있으므로 이는 선택적 가이드라인입니다.

비교 : 

대부분의 레거시 시스템에서 SOAP를 준수하며, REST는 그보다 뒤에 고려하거나 웹 기반 시나리오에서의 더 빠른 대안으로 여기는 경우가 많습니다. REST는 유연한 구현을 제공하는 가이드라인 세트고, SOAP는 XML 메시징과 같은 특정 요건이 있는 프로토콜입니다.

REST API는 경량화되어 있기 때문에 사물 인터넷(IoT), 모바일 애플리케이션 개발, 서버리스(servreless) 컴퓨팅과 같이 보다 새로운 컨텍스트에 이상적입니다. SOAP 웹 서비스는 많은 기업에서 필요로 하는 기본 보안과 트랜잭션 컴플라이언스를 제공하지만, 이로 인해 좀 더 무거운 경향이 있습니다. 또한 Google Maps API와 같은 대부분의 퍼블릭 API는 REST 가이드라인을 따릅니다.

출처 : 

https://mygumi.tistory.com/55

https://www.redhat.com/ko/topics/integration/whats-the-difference-between-soap-rest

https://lookingfor.tistory.com/entry/SOAP-REST-API

https://devkingdom.tistory.com/12 (SOAP 정리 잘되어있음)

정의 : 

데이터베이스의 설계를 재구성하는 테크닉입니다

정규화를 통해 불필요한 데이터 (redundancy)를 없앨 수 있고, 삽임/갱신/삭제 시 발생할 수 있는 각종 이상현상들을 방지 할 수 있습니다.

목적 : 

1. 불필요한 데이터를 제거

2. 데이터 저장을 "논리적"으로 한다.

함수적 종속이란?

어떠한 릴레이션에서 속성들의 부분 집합을 X, Y라 할때 특정 튜픙레서 X의 값이 Y의 값을 함수적으로 결정한다면 Y가 X에 함수적으로 종속되었다고 합니다.

함수적 종속의 추론 규칙은 아래와 같습니다.

• 재귀 규칙 : Y가 X의 부분 집합이면 X → Y 이다.
• 증가 규칙 : X → Y 이면 WX → WY 이고 WX → Y 이다.
• 이행 규칙 : X → Y 이고 Y → Z 이면 X → Z 이다.
• 유니온 규칙 : X → Y 이고 X → Z 이면 X → YZ 이다.
• 분해 규칙 : X → YZ 이면 X → Y와 X → Z 이다.
• 가이행 규칙 : 만일 W → X 이고 XY → Z 이면 WY → Z 이다.

종류 : 

1차 정규화 - 2차 정규화 - 3차 정규화 - BCNF - 4차 정규화 - 5차 정규화

실무적으로는 4차까지 가는 경우는 거의없다고 한다.

1차정규화

각 로우마다 컬럼의 값이 1개씩만 있어야 합니다. 이를 컬럼이 원자값(Atomic Value)를 갖는다고 한다.

위의 그림처럼 Adam이 2가지 속성을 가지고 있어서 분리해야 한다.

이렇게 되면 데이터 redundancy는 증가하게 된다.

2차 정규화

테이블의 모든 컬럼이 완전 함수적 종속을 만족해야 한다.

기본키중에 특정 컬럼에만 종속된 컬럼(부분적 종속)이 없어야 한다.

위 테이블의 경우 기본키는 (Student, Subject) 두 개로 볼 수 있습니다. 이 두 개가 합쳐져야 한 로우를 구분할 수가 있습니다. 근데 Age의 경우 이 기본키중에 Student에만 종속되어 있습니다. 즉, Student 컬럼의 값을 알면 Age의 값을 알 수 있습니다. 따라서 Age가 두 번 들어가는 것은 불필요한 것으로 볼 수 있습니다.

3차 정규화

기본키를 제외한 속성들 간의 이행적 함수 종속이 없는것

풀어서 말하자면, 기본키 이외의 다른 컬럼이 그 외 다른 컬럼을 결정할 수 없는 것.

2차 정규화와 마찬가지로 테이블을 분리하면서 해결가능

정규화 후

BCNF

3차정규형을 만족하면서 모든 결정자가 후보키 집합에 속한 정규형

아래와 같은 경우를 생각해보면, 후보키는 수퍼키중에서 최소성을 만족하는 건데, 이 경우 (학생, 과목) 입니다. (학생, 과목)은 그 로우를 유일하게 구분할 수 있습니다. 근데 이 테이블의 경우 교수가 결정자 입니다. (교수가 한 과목만 강의할 수 있다고 가정) 즉, 교수가 정해지면 과목이 결정됩니다. 근데 교수는 후보키가 아닙니다. 따라서 이 경우에 BCNF를 만족하지 못한다고 합니다. 3차 정규형을 만족하면서 BCNF는 만족하지 않는 경우는 언제일까요? 바로 일반 컬럼이 후보키를 결정하는 경우입니다.

 위와 같이 테이블이 구성된 경우에 데이터가 중복되고, 갱신 이상이 발생합니다. 예를 들어 Mr.Sim이 강의하는 과목명이 바뀌었다면 두 개의 로우를 갱신해야합니다. 이를 해결하기 위해서는 마찬가지로 테이블을 분리합니다.

교수 테이블

수강 테이블

제4 정규형 :

다치 종속 제거

제5 정규형 :

조인 종속성 제거

출처 : 

https://nirsa.tistory.com/107

https://mangkyu.tistory.com/110

https://3months.tistory.com/193

API란

API란 Application Programming Interface의 약자로,

응용프로그램에서 사용할 수 있도록, 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

그중 OPEN API란 사용자가 제공되는 데이터를 자유롭게 활용할 수 있도록 만들어 놓은 인터페이스이다.

대부분의 API로 제공되어지는 형태는 대부분 JSON이나 XML로 제공된다

• XML

• JSON

이런 형식으로 데이터의 결과값을 얻을 수 있다. 그냥 결과를 쓰기에는 어지럽고, 지저분하다.

그래서 얻은 데이터를 가공하는 과정을 거쳐야 한다.

이번에는 그중 JSON 파일의 형식을 알아보겠다.

JSON

정의 :

JavaScript Object Notation의 약자로, Key와 Value 쌍으로 이루어진 형태의 Object이다.

형식 : 

"result" : "00"

여기서 result는 Key / 00은 Value가 된다.

약자에서 알수있듯이, JavaScript에서 나온 포맷이다.

참고 및 추가적인 OPEN API 활용 사례 : 

https://velog.io/@garam0410/Java-OPEN-API-%ED%8C%8C%EC%8B%B1%ED%95%98%EA%B8%B0-JSON

A(Atomicity-원자성)

하나의 원자 트랜잭션은 모두 성공하거나 또는 실패하는 데이터베이스 운용의 집합이다.

C(Consistency-일관성)

트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지한다.

I(Isolation-고립성)

트랜잭션을 수행하는 도중에 다른 연산작업이 끼어들지 못하도록 한다.

D(Durability-지속성)

성공적으로 수행된 트랜잭션은 영원히 반영되어야 한다.

참고 : 

https://velog.io/@jonah/Acid%EB%9E%80

https://covenant.tistory.com/85