일단 하나를 해보자

웹서비스를 개발할 때 늘 사용하는 REST API에 대해 알아보자

그리고 REST API를 어떻게 설계해야하는지

REST API의 버전을 어떻게 관리해야하는지 정리해보고자 한다.

API란?

Application Programming Interface 애플리케이션 프로그래밍 인터페이스의 약자이다.

여기서 인터페이스는 장치라는 뜻으로 애플리케이션끼리의 통신을 도와주는 중개자 역할을 한다.

즉, 많이들 말하는 API 문서란

어떻게 요청을 하고 어떤 형식으로 응답을 할지, 통신을 어떻게 주고 받을지

약속이 적힌 문서와도 같다.

이러한 통신규약 역할을 하는 API는 REST API뿐아니라 GraphQL, gRPC 등 다양한 종류를 가지고 있다.  

그렇다면 REST API의 특징은 무엇일까?

REST API는  Representational State Transfer의 약자로 restful한 API라고도 한다.

"restful하다는 것은 restful 원칙에 부합하다는 것"을 뜻한다.

restful 원칙에 부합한 인터페이스가 REST API인 것이다.

restful원칙이란?

1. Uniform Interface 균일한 인터페이스

아래와 같은 특징을 가진 인터페이스여야 한다. 

• 각 자원은 고유한 식별자를 가져야한다.
  • 인터페이스는 클라이언트와 서버간에 상호작용에 관련된 각 리소스를 고유하게 식별해야한다.
  • 예) http URI --식별가능-->고유한 주소로 보내겠다  , application/json --식별가능--> json으로 보내겠다
• 표현을 통한 상태 전달
  • 리소스는 서버 응답에 균일한 표현을 가져야한다.
  • 예) 서버 응답 상태코드, 미디어 타입 content-type ..

• 자체 설명 메시지
  • 각 리소스 표현에는 메시지 처리 방법을 설명하는데 충분한 정보가 포함되어야한다. 설명 필요없이 자체만으로도 어떻게 처리해야되는지 이해가 되어야한다.
  • 예) GET, POST,, JSON 어떻게 처리할지 
• 애플리케이션 상태의 엔진으로서의 하이퍼미디어 
  • 클라이언트는 애플리케이션의 초기 URI만 가지고 있어야한다. 클라이언트 애플리케이션은 해당 url을 사용해 다른 모든 리소스와 상호작용을 한다. 

2. 클라이언트 - 서버 통신

클라이언트와 서버 통신 구조를 가진다. 

3. 무상태 

http프로토콜을 기반으로 하는 rest api는 http의 특성을 그대로 물려받았다.

그리하여 무상태 특징을 가진다.

무상태란, 서버가 클라이언트의 이전 상태를 저장하지 않고 독립적으로 처리되어야함을 뜻한다.

http 요청은 독립적이어서 이전 요청과 상태정보를 공유하지 않는다. 

4. 캐시를 사용할 수 있다. 

http를 사용하기 때문에 http의 캐시 저장 기능을 사용할 수 있다.

무상태 특징으로 이전 요청에 대해 상태를 공유하지 않는다.

그 결과, 동일 요청에 대한 응답이 일관적이다!

특정 url을 가지고 이전에 어떤 요청을 했든 상관없이 동일 요청 동일 url에 대한 응답이 같기 때문에

응답데이터를 캐시로 저장하고 사용하기 좋다.

5. 계층화 Layered System

요청과 응답이 분리되어 계층화된 레이어로 시스템을 구성할 수 있다. 예로 MVC 패턴이 있다.

http프로토클을 기반으로 하는 REST API는

표준 HTTP 메서드(GET, POST, PUT, DELETE..)와 URI(Uniform Resource Identifiers)를 사용하여 리소스를 식별한다.

결론적으로 

REST API는

클라이언트와 서버의 통신에 있어

리소스를 알아보기 쉽게 표현한, 통일된 인터페이스를 구성하는 것을 목적으로 한다. 

REST는 크게 다음과 같이 구성되어있다. 

• 자원 : HTTP URL
• 자원에 대한 행위: HTTP Method 
• 자원에 대한 표현: Representation

REST API 설계 규칙을 알아보자

1. 엔드포인트에 동사 대신 명사를 사용한다. 

HTTP 요청 메서드에 이미 동사가 있기 때문이다. 

만약 개발자가 선택적으로 동사를 넣는다면 불필요하게 길어지기만 할 뿐이다. 

작업은 HTTP 요청 메서드로 표시되어야한다. 

• GET 리소스 검색한다
• POST 새 데이터를 서버에 제출한다
• PUT 기존 데이터를 업데이트한다
• DELETE 데이터를 제거한다

동사는 다음처럼 CRUD 작업에 매핑된다

만약 쇼핑몰에서 옷을 가져온다면 

다음과 같은 'HTTP 메서드 작업 + 경로' 로 이루어진다.

GET /articles/

새 기사를 추가한다면

POST /articles/:id

기존 기사를 삭제한다면 

DELETE /articles/:id

이처럼 경로 자체에는 동사가 없어야한다. 

2. 엔드포인트에 논리적 중첩을 사용한다

엔드포인트를 디자인할 때 관련 정보가 포함된 엔드포인트를 그룹화하는 것이 좋다. 

한 개체가 다른 개체를 포함할 수 있는 경우 이를 반영해 디자인할 수 있다.

실제 데이터베이스에 어떻게 구성되어있는지와 상관없이 설정해주면 좋다. 

오히려 엔드포인트에서 데이터베이스 구조를 그대로 가져오는 것이 좋지 않다. 

각 기사에 대해 고유한 댓글이 있을 때 이 댓글을 가져올 때 

/articles/:articleId/comments 

경로로 묶어줄 수 있다. 

하지만 중첩이 너무 심하지 않게 아예 새로운 경로로 만들어주는 방법도 고려해야한다. 

예로 댓글에 대한 작성자를 

"/users/:userId" 로 만들 수도 있다.

3. 표준 오류 코드를 적절히 반환한다.

API를 통해 오류가 발생했을 때 이에 적절히 대처할 수 있도록

HTTP 상태코드로 오류 코드를 반환해야한다.

4. 데이터 필터링이 필요하다. (필터링, 정렬, 페이지 매김)

 코드를 API를 이용해 한번에 너무 많은 데이터를 반환하려고 하면 안된다. 

따라서 항목을 필터링하는 방법이 필요하다.

쿼리 문자열을 이용해 정렬할 필드를 지정할 수도 있고 url을 통해 쿼리 문자열을 추출할 수도 있다. 

5. 보안을 유지해야한다.

API를 통해 클라이언트와 서버가 통신하는 동안, 중요한 데이터가 유실될 수도 있다.

이를 막기 위해 디지털 인증서 " SSL 보안소켓 계층, TLS 전송계층보안"를 사용한 

HTTPS 프로토콜이 있다.

6. REST API Versioning 버전관리 전략을 사용한다.

운영중인 서비스의 API를 업데이트하는 경우 API versioning 전략이 필수적이다. 

클라이언트는 기존 REST API를 계속 사용하다 준비가 되면 최신 API로 마이그레이션 할 수 있다. 

1) 엔드포인트 경로를 통한 버전 관리 

http://www.example.com/v1

 기본적으로 가장 많이 사용한다 API 시작부분에 /v1, /v2 등을 추가한다. 직관적이고 간단하다는 장점이 있다.

2) 쿼리 매개변수를 통한 버전관리

http://www.example.com/product?version=1 

3) 사용자 정의 헤더를 통한 버전관리

curl -H "Accepts -version:1.0"

맞춤헤더가 필요하다.

하지만 버전관리로 url이 복잡해지지 않는다는 장점이 있다.

4) 콘텐츠 협상을 통한 버전관리 

6. 슬래시 는 계층관계를 나타나는데 사용되며 url마지막에는 포함하지 않는다. 

http://www.example.com/artlists/arts 

7. _ 언더바는 사용하지 않고 - 하이픈을 사용한다.  

8. 대문자 대신 소문자를 사용한다.

9. 파일 확장자는 URI에 포함하지 않는다.

출처: 

https://restfulapi.net/

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

axios는

지원하는 브라우저가 더 많고 

에러핸들링이 좋고

자동으로 데이터가 json형태로 되어 넘어간다

Automatic JSON data transformation

As we saw earlier, Axios automatically stringifies the data when sending requests (though you can override the default behavior and define a different transformation mechanism). When using fetch(), however, you’d have to do it manually.

Compare:

// axios
axios.get('https://api.github.com/orgs/axios')
  .then(response => {
    console.log(response.data);
  }, error => {
    console.log(error);
  });

// fetch()
fetch('https://api.github.com/orgs/axios')
  .then(response => response.json())    // one extra step
  .then(data => {
    console.log(data) 
  })
  .catch(error => console.error(error));

fetch는 직접 json화를 해줘야하지만

지원하는 브라우저 문제 등을 충분히  해결할 수 있다.

결론

Axios는 대부분의 HTTP통신 요구사항을 위해 컴팩트 패키지로 사용하기 쉬운 API를 제공한다.

하지만 fetch()메소드를 사용해서도 Axios 라이브러리의 주요기능을 완벽하게 재현할 수 있다.

는 글

https://blog.logrocket.com/axios-vs-fetch-best-http-requests/

https://medium.com/@dongha.sohn/bitcoin-8-%ED%95%A9%EC%9D%98-consensus-90e879d80b16

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=gitacademy01&logNo=222027103524 

(이거는 비교조건/p2p개념 링크)

주의!

나름의 이해라서 백퍼 맞지 않을 수 있음ㅎㅎ

(이해를 돕기 위해 설명해준 학우분 감사합니다.)

수업에서 블록생성하고 연결하고 검증하고 서버열어서 블록보여주고 이런 걸 해봤는데

드는 생각이 왜 p2p를 하지? 였음

노드간의 통신을 작동해야된다는데

local3001 서버 열고 여기서 블록생성하고 검증하면 여기가 중앙서버고

노드, 참여자용 서버로 만든 6001, 6002,6003은 블록 생성해서 중앙서버가 검증자해주는 건가? 

잉 그러면 탈중앙화가 아닌데? 혼돈;;;

내가 이해를 잘못하고 있었음

"먼저 블록 채굴에 성공한 채굴자는 해당 블록을 주변에 전파하게 된다. 중요한 사실은, 이때 전파하는 블록은 채굴에 성공했다고 확신할 수 없는 블록이며 검증을 거쳐 블록체인에 연결되어야 한다. 거래는 노드들에게 전파되며 검증의 과정을 거치듯, 블록 또한 검증을 거치게 되며 검증의 조건은 다음과 같다....."

우리 p2p하려고 웹소켓 써서 주고받는 통신하잖아

그 전에는 기본 포트는 컴퓨터 내에서 물리적으로 연결되어있으니까 접속이 가능한거고

웹소켓으로 내 컴퓨터를 3개의 컴퓨터로 분리하다고 치고 6001, 6002, 6003에 하나씩 컴퓨터가 있고

실제로는 하나니까 물리적으로 3001에 연결될 수 있는거라 서버는 3001만 열어도 될거같기도하고..

암튼 결론은!

내가 연 3001은 그냥 이 모든게 보이는 용도로만 쓰이는 보여주기용 서버이고 

실제로 블록 생성, 검증은 

노드들이 하는거임

노드들의 서버 6001, 6002, 6003

그니까 얘네끼리 통신하는 p2p서버로 하는거지.

처음에 시작했을 때 

제네시스 블록을 모든 노드들이 갖고 시작하고 

그 뒤에 줄줄이 블록을 생성하는 거임

이제 검증과정을 거쳐서 서로블록을 비교하고

황금블록 발견한 애꺼가 당첨되면 원본 블록체인에 연결되고

나머지는 허탕치고 다시 다음블록 만드는 거임

그 checkedValid 코드부분은 

//블록구조 유효한지
//현재 블록의 인덱스가 이전 블록의 인덱스보다 1만큼 큰지
//이전블록의 해시값과 현재 블록의 이전해시가 같은지
//데이터 필드로부터 계산한 머클루트와 블록헤더의 머클루트가 동일한지
//이 조건 다 맞으면 올바른 구조체이다

이 조건들로 블록이 진짜인지 증명하는거고

진짜 블록이어도 아직 당첨은 안된거지 원본에 연결안된거

이제 비교해서 당첨될라면

p2p끼리 통신..

누구꺼를 연결할걸로 할지...

chainedBlock에 

replaceChain 함수 주석처리 해놨는데 이거가 

p2pServer.js에서 이렇게 함수호출되어있음

이걸로 누구꺼 연결할지 찾는거 아닐까 짐작..

블록들 비교까지 한다면

 어떻게 하는지는 모르겠다 어렵다!!!

아무튼 해야되는거는 

블록마이닝(채굴)/ 지갑생성/ 현재 상황 시각화 / DB 채굴 저장

사실상 지갑생성까지 수업때 한거긴한데

위같은 비교검증은 없어서

완전한 블록체인은 아닌거같고..흠 

HTTP(Hyper Text Transfer Protocol)

웹 상에서 클라이언트와 서버가 서로 정보를 주고받을 수 있도록 하는 규약

우선 클라이언트는 서버에 정보(데이터) 전송을 요청(Request)할 수 있는 클라이언트 소프트웨어(크롬, IE, 사파리 등 웹 브라우저가 대표적)가 설치된 컴퓨터를 의미한다. 클라이언트는 URL(Uniform Resource Locator)로 된 HTTP를 통해 서버에게 정보 송신을 요청합니다. 우리가 평소 쓰는 URL 구조를 구분해 살피면 각각은 아래와 같은 의미를 가짐.

URL의 예: http://www.wishket.com/company-intro
1. http://: 자원에 접근하기 위한 http 프로토콜
2. www.wishket.com: 서버의 위치
3. company-intro: 서버에서 컴퓨터가 요청한 자원의 위치 

클라이언트가 이렇게 정보 송신을 요청하면 서버는 대응한다. 서버는 응답하는(Response) 소프트웨어(아파치, nginx, IIS 등)가 설치된 컴퓨터를 의미한다. 서버는 클라이언트의 요청을 해석하고 클라이언트의 요청 및 서버 관리자가 설정한 알고리즘에 준하는 정보를 클라이언트에게 송신한다.

위의 내용을 정리하면 HTTP를 통해 이런 일이 이루어짐~

1. 클라이언트가 보고 싶은 정보를 서버에게 HTTP를 통해 요청.
2. 서버는 알맞은 응답 메시지 및 정보를 클라이언트에게 전달.
3. 응답 메시지 및 정보 중 HTTP바디 내용이 클라이언트가 설정한 클라이언트의 용처에 도달한다.

HTTP의 구조

HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며 Method, Path, Version, Headers, Body 등으로 구성된다.

하지만 HTTP는 암호화가 되지 않은 평문 데이터를 전송하는 프로토콜이라서 보안 취약

이 문제 해결하기 위해 HTTPS가 등장

HTTPS

HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure 등으로 불리는 HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 공개키 암호화를 지원하고 있다.

‘HTTP vs HTTPS 차이’

바로 SSL(보안 소켓 계층) 인증서

사실 HTTPS는 쉽게 말해서 HTTP 프로토콜에 보안 기능을 추가한 것

SSL 인증서는 사용자가 사이트에 제공하는 정보를 암호화하는데, 쉽게 말해서 데이터를 암호로 바꾼다고 생각하면 쉽다. 이렇게 전송된 데이터는 중간에서 누군가 훔쳐 낸다고 하더라도 데이터가 암호화되어있기 때문에 해독할 수 없다. 그 외에도 HTTPS는 TLS(전송 계층 보안) 프로토콜을 통해서도 보안을 유지. TSL은 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하고, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공하고 있습니다

사실 HTTPS로 전환하게 되면 검색엔진 최적화(SEO)에 있어서도 큰 혜택을 볼 수 있음

또한 가속화된 모바일 페이지(AMP, Accelerated Mobile Pages)를 만들고 싶을 때도 HTTPS 프로토콜을 사용해만 함 

출처

• https://mangkyu.tistory.com/98[MangKyu's Diary]
• http://blog.wishket.com/http-%ea%b7%b8%eb%a6%ac%ea%b3%a0-https%ec%9d%98-%ec%9d%b4%ed%95%b4/
• http://blog.wishket.com/http-vs-https-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EB%A9%B4-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A0%88%EB%B2%A8%EC%9D%B4-%EB%B3%B4%EC%9D%B8%EB%8B%A4/