postman은 이클립스에서 Spring
을 만들 때 사용한다. 인텔리제이에서는 .http
라는 방법이 있다.
API 개발을 보다 빠르고 쉽게 구현할 수 있도록 도와주는 테스트 결과를 공유하며 API개발의 생산성을 높여주는 플랫폼이고 여러 방식의 요청을 외부에서 보낼 수 있도록 도와주는 개발 툴이다. 만들면서 테스트하는 용도로 사용한다. 예를 들어, 스프링으로 ajax나 axios로 기능을 구현하고 그것이 제대로 돌아가는지 테스트하기 위해서 사용한다.
GET, POST 외에도 PUT, DELETE 등의 요청도 가능하다.
REST API 설계 개발, 테스팅을 할 수 있는 GUI툴로 개발 생산성을 높여주는 프로그램
팀원들 간의 공유 가능
Query String이 포함된 GET방식 호출
JSON이 사용된 POST 방식 호출
Authorization을 이요한 oauth 요청
계정 별로 API 사용에 대한 내용과 기록을 저장할 수 있습니다.
테스트한 API의 입력 정보를 기록하고 저장할 수 있습니다. Save As... 클릭하기
개발 중인 앱에 회원가입, 로그인, 로그아웃, 포스트 등을 구현하고 테스트 하기 위해서는 클라이언트가 필요합니다.
클라이언트에서 특정 주소로 보내준 정보와 요청을 토대로 서버에 구현한 로직을 처리하기 위해서입니다. 예를 들어 회원가입이라면 localhost::PORT/api/user/register라는 라우터로 이메일, 비밀번호 등의 정보를 보냅니다.
서버는 이 정보를 받아서 회원을 만들어 데이터베이스에 저장해야 합니다. 하지만 특정 주소로 정보를 보내줄 클라이언트(프론트 엔드)가 아직 개발되지 않았다면 포스트맨이라는 프로그램으로 쉽게 테스트 할 수 있습니다.
post의 경우 html 클라이언트에서 form, 버튼, 이벤트, 이벤트 등록, 등등등... 백엔드를 구현하기 전 우선 만들어져야 하는 것들이 있다. 그럼 백엔드가 프론트엔드가 구현되기를 기다려야하는 상황이 발생한다. => 이러한 불편함을 개선하기 위해 postman 탄생
postman은 가벼운 툴이다.
Rest API를 표현할 수 있다.
협업할 때 팀원이 만든 url을 확인할 때 편리하다.
인터페이스를 구축해 놓은 툴인 Postman 을 사용하게 되면 변수 및 환경, Request, 테스트 등 자유롭게 가능하고 테스트한 환경, 요청한 Request History 등 이 그대로 저장되어 시간과 장소에 구애받지 않고 나의 작업환경을 다시 쉽게 가져올 수 있다.
대량의 엑세스가 있는 서비스에서는 서버 1대로 처리할 수없는 부하를 어떻게 처리할 것인지가 가장 큰 문제다. 최근 10년 동안의 트렌드로는 이른바 스케일 아웃(scale-out)이 이문제에 대한 전략의 기초가 된다. 스케일아웃은 서버를 횡으로 전개, 즉 서버의 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인 처리능력을 높여 처리능력을 끌어올리는 방법이다.
하드웨어의 성능과 가격은 비례하지 않는다. 대량생산되고 있는 일용품 성격의 하드웨어일수록 저가에 구할 수 있다. 저가의 하드웨어를 횡으로 나열해서 확장성을 확보하는 것이 스케일 아웃 전략이다. 이 전략을 채용한 경우 비용이 절감되지만 다양한 문제가 있다. 예를들면 사용자로부터의 요청을 어떻게 분배할 것인가? 해답으로는 로드밸러서를 사용한다는 것인데, 서버 1대일 때에는 애초에 로드밸런서를 도입하는 것 자체를 생각할 필요도 없다.
데이터 동기화는 어떻게 할것인가? DB를 분산시켰을 때 한쪽에 저장된 갱신 내용을 다른 한쪽 DB가 알지 못한다면 애플리케이션에 비정상 사태가 발생한다.
네트워크 통신의 지연시간을 어떻게 생각해볼 수 있을까? 작은 데이터라도 이더넷을 경유해서 통신한 경우는 밀리초 단위의 지연시간이 있다. 밀리초라고 하면 사람이 체감하기로는 그다지 긴 시간이 아니더라도 마이크로초나 나노초에 작동하는 컴퓨에 있어서는 매우 긴 시간이다. 통신의 오버헤드를 최소한으로 줄여가면서 애플리케이션을 구성해갈 필요가 있다. 그 밖에 스케일아웃에 동반하는 문제는 다방면에 걸쳐있다.
시스템은 다중성을 지닌 구성, 즉 특정 서버가 고장 나거나 성능이 저하되더라도 서비스를 계속할 수 있는 구성으로 할 필요가 있다. 스케일아웃을 해서 서버 대수가 늘어나면 서버의 고장률도 필연적으로 올라가게 된다. 그러므로 어딘가 잘못되면 전부 정지하는 설계는 계속 가동되어야 하는 웹 서비스에서는 용납할 수 없다. 서버가 고장 나더라도 부하가 올라갈 경우에도 견딜 수 있는 시스템을 구성할 필요가 있다. 서비스가 대규모화되면 될 수록 시스템 정지의 사회적 충격도 늘어나므로 더욱 더 다중성 확보
가 중요해진다.
감시용 소프트웨어를 사용하고 정보관리를 위한 툴을 사용하는 등 자동화를 하게 된다.
그러나 이 감시 소프트웨어를 설치하거나 정보를 보든 것은 결국 인간이다. 일손을 거치지 않고 대규모 시스템을 건강한 상태로 얼마나 계속 유지할 수 있 있을것인가? 이를 위한 효율적 운용
을 수행해야 한다.
이 책에서 가장 큰 테마가 바로 데이터량이다. 컴퓨터는 디스크에서 데이터를 로드해서 메모리에 저장, 메모리에 저장된 데이터를 CPU가 패치해서 특정 처리를 수행한다. 또한 메모리에서 패치된 명령은 보다 빠른 캐시 메모리에 캐싱된다. 이처럼 데이터는 디스크 → 메모리 → 캐시 메모리 → CPU와 같이 몇 단계를 경유해서 처리한다.