개발새발, 써놓기

API란?
API는 어떤 서버의 특정한 부분에 접속해서 그 안에 있는 데이터와 서비스를 이용할 수 있게 해주는 소프트웨어 도구이다. API를 이용하면 두 개의 소프트웨어가 서로 통신을 주고받을 수 있다.

REST API?
네트워크를 통해서 컴퓨터들끼리 통신할 수 있게 해주는 아키텍처 스타일이다.

인터넷 식별자(URI)와 HTTP 프로토콜을 기반으로 한다.
HTTP프로토콜 덕분에 단순함이 핵심이다.
클라이언트-서버 모델로 구축되었다는 것을 의미.
웹에 최적화되어있고 주로 JSON을 사용해 브라우저들 간에 호환성이 좋다. 

- 사용하기 쉽다.
- 배우기 쉽다.
- SOAP는 모든 메시지에 XML을 사용하지만 REST는 JSON을 주로 사용해 가볍다.
- 빠르다.


SOAP API?
그 자체로 프로토콜이며, 보안이나 메시지 전송 등에 있어서 REST보다 더 많은 표준들이 정해져 있기 때문에 복잡하다. 이러한 표준들로 오버헤드가 많지만 보안, 트랜잭션 등을 준수해야 하는 종합적인 기능이 필요한 조직에게는 적합한 방식이다. (기업용 애플리케이션 작업에 이상적) 데이터 포맷으로 XML만을 사용한다.
SOAP 표준에는 성공/반복 실행 로직이 규정되어 있기 때문에 SOAP API를 통해서 통신을 할 때 처음부터 끝까지 신뢰성을 제공한다.

- 언어, 플랫폼, 전송 독립적 (REST는 HTTP가 필요)
- 분산된 기업환경에 적합 (REST는 직접적인 point-to-point 통신)
- 표준화
- WS 표준에 따라 전처리 확장성을 제공한다.
- 빌트인 에러 다룬다.



REST와 SOAP는 각기 다른 두 가지의 온라인 데이터 전송 방식입니다. 둘 다 웹 애플리케이션 간 데이터 통신을 허용하는 애플리케이션 프로그래밍 인터페이스(API)를 구축하는 방법을 정의합니다. REST는 아키텍처 원칙 세트이고, SOAP은 W3c에서 유지관리하는 공식 프로토콜입니다.

REST
1. REST는 웹 서비스와 모바일 애플리케이션 경량화의 필요에 맞춘 아키텍처 원칙 세트.
2. 데이터 요청이 전송될 때 HTTP를 통해 이루어진다. 요청을 수신하면 REST용으로 설계된 API가 HTML, XML, 일반 텍스트, JSON과 같은 다양한 형식으로 메시지를 반환할 수 있다.
JSON은 어떠한 프로그래밍언어로든 읽을 수 있고, 인간과 기계 모두 읽을 수 있고, 경량화되어있기 때문에 선호되는 메시지 형식이다.

RESTful 애플리케이션이 갖춰야 할 요소
1. 클라이언트, 서버, 리소스로 구성된 클라이언트-서버 아키텍처가 필요하다.
2. 요청이 통과하는 서버에 클라이언트 콘텐츠가 저장되지 않는 stateless 클라이언트-서버 커뮤니테이션이 필요하다. (대신 세션의 상태에 대한 정보가 클라이언트에 저장된다.)
3. 일부 클라이언트-서버 간 상호 작용의 필요성을 제거할 캐시 가능 데이터가 필요하다.
4. 애플리케이션 요구 사항별로 표준화된 형식으로 정보를 전송할 수 있도록 구성 요소 간 통합된 인터페이스가 필요하다.
5. 클라이언트-서버 간의 상호 작용을 계층적으로 조정할 수 있도록 계층화된 시스템 제약이 필요하다.
6. 실행 가능한 코드를 전송해 서버가 클라이언트의 기능을 확장할 수 있게 해주는 코드 온디맨드가 필요하다.

SOAP
SOAP는 다른 언어로 다른 플랫폼에서 빌드된 애플리케이션이 통신할 수 있도록 설계된 최초의 표준 프로토콜이다. 프로토콜이기 때문에 복장성과 오버헤드를 증가시키는 빌트인 룰을 적용하므로, 페이지 로드 시간이 길어질 수 있다. 빌트인 컴플라이언스를 제공하므로 기업에서 선호하는 방식. 빌트인 컴플라이언스 표준에는 보안과 트랜잭션 ACID가 포함된다.

웹 서비스 보안 : 토큰이라고 불리는 고유 식별자를 통해 메시지를 보호하고 전송하는 방식을 표준화한다.
WS-ReliableMessaging : 불안정한 IT인프라로 전송되는 메시지 간 오류 처리를 표준화합니다.
웹 서비스 주소지정 WS-addressing : 심층 네트워크에 라우팅 정보를 유지관리하는 대신, SOAP 헤더 내에 메타데이터로 해당 정보를 패키징한다.
웹 서비스 기술 언어 WSDL : 웹 서비스가 무엇을 하는지, 해당 서비스의 시작과 종료 위치를 기술합니다.
데이터에 대한 요청이 SOAP API로 전송되는 겨우 HTTP(웹 브라우저), SMTP(이메일), TCP 등의 다양한 애플리케이션 레이어 프로토콜을 통해 처리될 수 있다. 그러나 요청이 수신되면, 인간과 기계가 모두 읽을 수 있는 마크업언어인 XML 문서 형식으로 반환 SOAP 메시지가 반환된다. SOAP API에 대한 완료된 요청을 브라우저에서 캐시할 수 없으므로, API로 재정송하지않는 한 이후에 액세스할 수 없다.

SOAP - REST 차이
REST는 유연한 구현을 제공하는 가이드라인 세트고, SOAP는 XML 메시징과 같은 특정 요건이 있는 프로토콜이다.

REST API 는 경량화되어 있기 때문에 IoT, 모바일 애플리케이션개발, 서버리스 컴퓨팅과 같이 보다 새로운 컨텍스트에 이상적이다. SOAP 웹 서비스는 많은 기업에서 필요로 하는 기본 보안과 트랜잭션 컴플라이언스를제공하지만, 이로 인해 좀 더 무거운 경향이 있다.

두 사이트를 참고해서 정리했습니다.

https://www.redhat.com/ko/topics/integration/whats-the-difference-between-soap-rest#%EA%B0%9C%EC%9A%94

https://www.soapui.org/learn/api/soap-vs-rest-api/

https://developer.mozilla.org/ko/docs/Learn/JavaScript/First_steps/What_is_JavaScript

위 사이트를 보고 개인적으로 정리하는 게시글입니다.

자바스크립트는 주기적으로 내용이 갱신되는 기능이나 능동적인 지도, 변화하는 2D/3D 그래픽, 동영상 등을 웹페이지에 적용할 수 있게 하는 스크립트 혹은 프로그래밍 언어입니다.

동적으로 컨텐츠를 바꾸고, 멀티미디어를 다루고, 움직이는 이미지 그리고 다른 일들을 할 수 있는 스크립트 언어이다.

Browser API는 웹 브라우저에 설치된 API들로, 컴퓨터 환경구성으로 부터 데이터를 보이게 하고 복잡한 일들을 하게 한다.

DOM (Document Object Model) API 는 동적으로 페이지의 스타일을 정하는 등 HTML과 CSS를 알맞게 조정하는 역할을 한다.

Geolocation API는 지리적인 정보를 검색하게 해준다. 

Canvas 와 WebGL API는 2D와 3D 그래픽을 만들 수 있도록 한다.

HTMLMediaElement와 WebRTC 같은 Audio and Video API는 음악과 비디오를 웹 페이지 상에서 재생하고, 웹캠으로 캡처하고 다른 컴퓨터에 표시하는 등의 멀티미디어를 활용할 수 있는 재미있는 기술을 지원한다.

Third party API 는 브라우저에 기본적으로 설치된 API가 아닌 인터넷에서 개인적으로 정보와 코드를 얻어 프로그래밍한 것을 말한다.

브라우저에서 웹페이지를 불러올 때, 실행 환경(브라우저 탭)안에서 HTML, CSS, Javascript 코드가 실행된다. 

자바스크립트는 HTML과 CSS가 결합되고 웹페이지 상에서 올려진 후, 브라우저의 자바스크립트 엔진에 의해 실행된다. 즉, 페이지의 구조와 스타일등을 정해놓고 자바스크립트가 실행된다는 의미.

브라우저에서 자바스크립트를 만났을 때 일반적으로 위에서 아래 순서대로 실행된다. (주의해서 코드를 작성해야 한다는 의미!)

해석형 언어와 컴파일러형 언어 ?

자바스크립트는 해석형 언어이다. 따라서 코드가 위에서 아래로 순차적으로 실행되고 그 즉시 결과가 반환된다. 브라우저에서 동작하기 전에 다른 방식으로 코드를 변환할 필요가 없다.

반면 컴파일러형 언어는 컴퓨터에 의해 동작되기 전 다른 형식으로 변환하는 언이이다. 예를 들면, C/C++과 같은 언어는 어셈블리어로 컴파일되어 동작된다.

서버측 코드와 클라이언트측 코드 ?

클라이언트측 코드란 사용자의 컴퓨터에서 작동되는 코드이다. 웹페이지를 보고자한다면, 클라이언트측 코드가 사용자의 컴퓨터로 다운로드되고 브라우저가 이를 표시한다. 이러한 자바스크립트 모듈을 정확히는 클라이언트측 자바스크립트라고 한다.

반면, 서버측 코드는 서버에서 작동되고 그 결과가 사용자의 브라우저에 넘어가 표시된다. PHP, Python, Ruby, ASP.NET등이 서버측 웹 언어의 대표적 예. 물론 자바스크립트도 Node.js란 환경을 통해서 서버측에서 자바스크립트가 사용 가능하다.

동적이라는 말은 클라이언트측 서버측 언어 모두를 가르킨다. 서버측 코드는 데이터베이스로부터 데이터를 던지는 등 동적으로 새로운 컨텐츠들을 만든다. 반면에, 클라이언트 측 자바스크립트는 새로운 HTML 표를 만들어 서버에서 요청한 데이터를 뿌려 사용자에게 보이는 등 동적으로 브라우저 안에서 작동된다. 

https://developer.mozilla.org/ko/docs/Learn/Getting_started_with_the_web/How_the_Web_works

위 링크를 보고 공부하는 겸 올립니다.

웹에 연결된 컴퓨터는 클라이언트와 서버라고한다.

클라이언트 ? 인터넷이 연결된 장치들과 이런 장치들에서 웹에 접근하는 소프트웨어(크롬, 파이어폭스 등의 웹 브라우저)

서버 ? 웹페이지, 사이트, 또는 앱을 저장하는 컴퓨터.

클라이언트의 장비가 웹페이지에 접근하길 원할 때, 서버로부터 웹페이지의 사본이 다운로드된다.

 + 알아야 할 내용

클라이언트가 브라우저에 웹 주소를 입력하면!

1) DNS 서버로 가서 서버의 진짜 주소를 찾는다.

2) 브라우저는 서버에 웹사이트의 사본을 클라이언트에게 보내달라는 HTTP요청메세지를 전송한다. (TCP/IP이용)

3) 클라이언트의 요청 메시지를 받은 서버는 요청을 승인하고 200 OK 메세지를 클라이언트에게 전송한다. 이 후 서버는 웹사이트의 파일들을 데이터 패킷이라 불리는 작은 일련의 덩어리들로 브라우저에 전송한다.

4) 브라우저는 받은 데이터 패킷을 웹사이트로 조립하고 클라이언트에게 보여준다.

1. VScode 를 킨다.

2. 확장으로 들어가 Github를 검색해 GitHub Repositories 를 다운로드 한다.

3. 원격 창 열기를 누른다. (Open Remote Repository 를 누름)

4. Open Repository from GitHub 를 누른다.

5. 이 후 본인의 아이디로 로그인 하고 이창이 뜨면 완료된다.

연동이 완료되면 밑에 내가 추가한 Repository 가 뜨고 누르면 그 Repository와 연결된 새로운 VSCode 창이 뜬다.

왼쪽 맨 밑에도 GitHub 라고 뜨고 작업폴더 옆에도 GitHub 라고 떠있는 것을 확인 할 수 있다.

이 후 커밋을 할 때는 메세지 창에 메세지를 입력하고 ∨ 체크모양을 누르면 된다.

※ 주의 할 점으로는 Eclipse 나 Spring 과는 달리, commit과 동시에 push가 되어 서버에 올라간다.

원래 commit 은 로컬 디스크에 서버에 올릴 것이 있다는 것을 저장하는 명령어이고 push가 실제로 서버에 올리는 명령어 인데 VScode 에서는 commit하니까 바로 Repository 에 올라갔다.

아마 이게 clone repository 가 아니라서 그런듯!

1) 깃에 레포지토리를 만든다.

2) 이클립스에 Window -> perspective -> other 에 들어가 Git을 누른다.

3) 새로운 아이콘이 Perspective 가 모여있는 곳에 생기는데, 거기서 Clone a Git Repository 를 누르고 1에서 만든 git Repository 주소를 넣는다.

인증관련해서는 (Authentication) >>

더보기

Settings 에 Developer settings 에 들어간다.

Personal access tokens 를 발급받아 사용하면 된다.

4) 새로운 자바프로젝트를 만든다.

5) 만든 자바프로젝트를 오른쪽 클릭 후 Team -> Share Project를 누른다.

6) 새로 뜨는 창에서 Repository를 3)에서 연결한 Git Repository 로 설정한다.

완료!

이상 Git 설치 없이 IDE로 연결하는 방법을 알아보았다.

HTTP(HyperText Transfer Protocol)

- 인터넷에서 하이퍼텍스트(hypertext)문서를 교환하기 위하여 사용되는 통신규약이다.

- www(World Wide Web)상에서 정보를 주고 받기 위한 프로토콜로, 애플리케이션 레벨의 프로토콜이다.

- HTTP는 TCP/IP 위에서 작동하며, 서버/클라이언트 모델을 따른다. 클라이언트에서 요청(request)를 보내면 서버는 요청을 처리해서 응답(response)한다.

- HTTP는 connection less 방식(stateless)이다. 클라이언트의 요청에 서버가 응답한 후 클라이언트와 연결을 끊는 구조로 network 속도가 느린 단점을 가지고 있다. 이를 개선하기 위해 HTTP 1.1부터는 Keep Alive 기능을 지원한다. Keep Alive 기능은 일정한 시간동안 접속을 유지하는 기능이다.

- 클라이언트가 서버에 접속하여 어떠한 요청을 하면, 서버는 세 자리 수로 된 응답 코드와 함께 응답한다.

- HTTP URL은 "http://"로 시작하며, 기본 포트번호는 80이다.

HTTPS(HyperText Transfer Protocol over Secure Socket Layer)

- HTTP는 기본적으로 평문 데이터 전송을 원칙으로 하기 때문에 개인의 프라이버시가 오가는 서비스들(전자상거래, 전자메일, 사내문서)에 사용하기 힘들다.

- HTTPS는 SSL위에 HTTP를 통과 시키는 방식이다. 평문의 HTTP 문서는 SSL를 통과하면서 암호화 돼서 목적지에 도착하고, 목적지에서는 SSL 레이어를 통과하면서 복호화돼서 웹 브라우저에 전달된다.

- SSL은 전자상거래에서의 데이터 보안을 위해서 개발한 통신 레이어다. SSL은 표현계층의 표현계층의 프로토콜로 응용계층 아래에 있기 때문에, 어떤 응용 계층의 데이터라도 암호화해서 보낼 수 있다.

- HTTPS는 인ㅇ증서를 이용해서, 접속 사이트를 신뢰할 수 있는지 평가할 수 있다.

- 일반적으로 HTTPS는 HTTP에 비해서 느리다. 많은 양의 데이터를 처리할 경우 성능의 차이를 체감할 수 있다.

- HTTPS URL은 "https://"로 시작한다.

- 기본포트번호는 443이다.

https://developer.mozilla.org/ko/docs/Web/HTTP

Ssgtudy 쓱터디 프로젝트를 진행하면서 쿼리에서 애를 먹은 부분.

페이징처리를 했을 때도 검색한 스터디의 순위는 일정해야 하는데, 검색한 것에서 해당하는 걸로만 빼지고 순위를 구하니까 원래 4등이었던 것이 1등으로 나오게 되는 경우가 발생했었다. 

그래서 자바에서도 처리를 해보았던 경우도 있었다. (일단 눈앞에 이 프로젝트는 많은 용량이 아니니까 그냥 할 수 있다고 쳐도, 후에 진짜 서비스에서는 힘들 것 같았다.) 

자바에서 처리했을 때 썼던 방식.

모든 행(자료)을 가져온다. 자바에서 questCount에 따라 정렬한다. (일단 이 때는 무조건 순위를 다르게 했음.) 그 arrayList에서 검색한다. (검색할 시에는 Linkedlist보다 arrayList가 더 빠르므로) 그러면 순위를 유지한 채로 자료를 가져올 수 있다. 하지만->

생각한 문제점 > 모든 데이터를 가져오게 되면 정보의 량이 (행의 수가) 엄청 많아지면 ? 

그냥 쿼리를 2개를 짜서 검색일 때와 아닐 때를 구문해서 내가 직접 매칭시켜줄까 싶었으나, 그러기엔 수정하기가 조금 귀찮 (!) 기도 했고 하나로도 할 수 있을 것 같아서 그 결과 이미지 쿼리가 되었다.

즉 keyword(검색값)이 있을 때는 제일 안쪽에 있는 서브쿼리(순위가 매겨져 있는 모든 자료)에서 검색한 이름에 부합하는 것들만 나오게!

keyword가 없을 때는 평소대로 페이징처리.

이렇게 했다.

https://github.com/sophia9999 

>(하지만 아직 검색값이 5000개가 넘는다면.....?? 그럼 검색의 의미가 없지 않을까? 검색어의 단어를 2글자 이상이라고 조건을 주는 것이 좋은가 생각해봐야될 문제

우선 버퍼에 대해 알아보자.

https://www.google.com/search?q=buffer&oq=buffer&aqs=chrome..69i57j69i59i433i512j0i512l5j69i61.3195j0j7&sourceid=chrome&ie=UTF-8 

구글 검색 시

데이터를 한 곳에서 다른 한 곳으로 전송하는 동안 일시적으로 그 데이터를 보관하는 메모리의 영역. 이라고 한다.

버퍼링이란 버퍼를 활용하는 방식, 버퍼를 채우는 동작을 말한다.

에서 검색해서 찾아보았다. 

우선

BufferedReader 클래스의 경우 문자입력으로부터 text를 읽어오는 클래스이다. 문자들을 버퍼에 채워서 문자, 배열 그리고 줄들을 효과적으로 읽도록 제공하는 클래이다.

BufferedWriter 클래스의 경우

text를 문자 출력으로 써주는 클래스이다. 문자, 배열 그리고 문자열등을 효율적으로 글쓰도록 도와주기 위해 버퍼에 채울때 사용하는 클래스이다.

백준에서 문제를 풀 때 썼던 클래스인데, Scanner 클래스를 이용하면 시간초과가 나올 수 있으니까 사용하라고 한 클래스였다. 대충 들어보긴했는데 자세히는 잘 모르겠어서 읽어보았다.