Restful API
1. RESTful API ?
RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다. 대부분의 비즈니스 애플리케이션은 다양한 태스크를 수행하기 위해 다른 내부 애플리케이션 및 서드 파티 애플리케이션과 통신해야 한다. 예를 들어 월간 급여 명세서를 생성하려면 인보이스 발행을 자동화하고 내부의 근무 시간 기록 애플리케이션과 통신하기 위해 내부 계정 시스템이 데이터를 고객의 뱅킹 시스템과 공유해야 한다. RESTful API는 안전하고 신뢰할 수 있으며 효율적인 소프트웨어 통신 표준을 따르므로 이러한 정보 교환을 지원한다.
2. RESTful API 장점
1) 확장성
REST API를 구현하는 시스템은 REST가 클라이언트-서버 상호 작용을 최적화하기 때문에 효율적으로 크기 조정할 수 있다. 무상태는 서버가 과거 클라이언트 요청 정보를 유지할 필요가 없기 때문에 서버 로드를 제거하고, 잘 관리된 캐싱은 일부 클라이언트-서버 상호 작용을 부분적으로 또는 완전히 제거합니다. 이러한 모든 기능은 성능을 저하시키는 통신 병목 현상을 일으키지 않으면서 확장성을 지원한다.
2) 유연성
RESTful 웹 서비스는 완전한 클라이언트-서버 분리를 지원한다. 각 부분이 독립적으로 발전할 수 있도록 다양한 서버 구성 요소를 단순화하고 분리한다. 서버 애플리케이션의 플랫폼 또는 기술 변경은 클라이언트 애플리케이션에 영향을 주지 않고, 애플리케이션 함수를 계층화하는 기능은 유연성을 더욱 향상시킨다. 예를 들어, 개발자는 애플리케이션 로직을 다시 작성하지 않고도 데이터베이스 계층을 변경할 수 있다.
3) 독립성
REST API는 사용되는 기술과 독립적이다. API 설계에 영향을 주지 않고 다양한 프로그래밍 언어로 클라이언트 및 서버 애플리케이션을 모두 작성할 수 있다. 또한 통신에 영향을 주지 않고 양쪽의 기본 기술을 변경할 수 있다.
3. RESTful API 작동 방법
RESTful API의 기본 기능은 인터넷 브라우징과 동일하다. 클라이언트는 리소스가 필요할 때 API를 사용하여 서버에 접속한다. API 개발자는 서버 애플리케이션 API 문서에서 클라이언트가 REST API를 어떻게 사용해야 하는지 설명한다. 다음은 모든 REST API 호출에 대한 일반 단계이다.
a) 클라이언트가 서버에 요청을 전송합니다. 클라이언트가 API 문서에 따라 서버가 이해하는 방식으로 요청 형식을 지정한다.
b) 서버가 클라이언트를 인증하고 해당 요청을 수행할 수 있는 권한이 클라이언트에 있는지 확인한다.
c) 서버가 요청을 수신하고 내부적으로 처리한다.
d) 서버가 클라이언트에 응답을 반환한다.
e) 응답에는 요청이 성공했는지 여부를 클라이언트에 알려주는 정보가 포함된다.
f) 응답에는 클라이언트가 요청한 모든 정보도 포함된다.
4. RESTful API 클라이언트 요청
고유 리소스 식별자
서버는 고유한 리소스 식별자로 각 리소스를 식별한다. REST 서비스의 경우 서버는 일반적으로 URL(Uniform Resource Locator)을 사용하여 리소스 식별을 수행한다. URL은 리소스에 대한 경로를 지정한다. URL은 웹페이지를 방문하기 위해 브라우저에 입력하는 웹 사이트 주소와 유사하다. URL은 요청 엔드포인트라고도 하며 클라이언트가 요구하는 사항을 서버에 명확하게 지정한다.
1) 메서드
개발자는 종종 Hypertext Transfer Protocol(HTTP)을 사용하여 RESTful API를 구현한다. HTTP 메서드는 리소스에 수행해야 하는 작업을 서버에 알려준다. 다음은 4가지의 일반적인 HTTP 메서드이다.
a) GET
클라이언트는 GET을 사용하여 서버의 지정된 URL에 있는 리소스에 액세스한다. GET 요청을 캐싱하고 RESTful API 요청에 파라미터를 넣어 전송하여 전송 전에 데이터를 필터링하도록 서버에 지시할 수 있다.
b) POST
클라이언트는 POST를 사용하여 서버에 데이터를 전송한다. 여기에는 요청과 함께 데이터 표현이 포함되고, 동일한 POST 요청을 여러 번 전송하면 동일한 리소스를 여러 번 생성하는 부작용이 있다.
c) PUT
클라이언트는 PUT을 사용하여 서버의 기존 리소스를 업데이트한다. POST와 달리, RESTful 웹 서비스에서 동일한 PUT 요청을 여러 번 전송해도 결과는 동일하다.
d) DELETE
클라이언트는 DELETE 요청을 사용하여 리소스를 제거한다. DELETE 요청은 서버 상태를 변경할 수 있지만 사용자에게 적절한 인증이 없으면 요청은 실패한다.
2) HTTP 헤더
요청 헤더는 클라이언트와 서버 간에 교환되는 메타데이터이다. 예를 들어, 요청 헤더는 요청 및 응답의 형식을 나타내고 요청 상태 등에 대한 정보를 제공한다.
3) 데이터
REST API 요청에는 POST, PUT 및 기타 HTTP 메서드가 성공적으로 작동하기 위한 데이터가 포함될 수 있다.
4) 파라미터
RESTful API 요청에는 수행해야 할 작업에 대한 자세한 정보를 서버에 제공하는 파라미터가 포함될 수 있다.
a) URL 세부정보를 지정하는 경로 파라미터
b) 리소스에 대한 추가 정보를 요청하는 쿼리 파라미터
c) 클라이언트를 빠르게 인증하는 쿠키 파라미터
5. RESTful API 서버 응답
1) 상태 표시줄
상태 표시줄에는 요청 성공 또는 실패를 알리는 3자리 상태 코드가 있다. 예를 들어, 2XX 코드는 성공을 나타내고 4XX 및 5XX 코드는 오류를 나타내고, 3XX 코드는 URL 리디렉션을 나타낸다.
200: 일반 성공 응답
201: POST 메서드 성공 응답
400: 서버가 처리할 수 없는 잘못된 요청
404: 리소스를 찾을 수 없음
2) 메시지 본문
응답 본문에는 리소스 표현이 포함된다. 서버는 요청 헤더에 포함된 내용을 기반으로 적절한 표현 형식을 선택하고, 클라이언트는 데이터 작성 방식을 일반 텍스트로 정의하는 XML 또는 JSON 형식으로 정보를 요청할 수 있다. 예를 들어, 클라이언트가 John이라는 사람의 이름과 나이를 요청하면 서버는 다음과 같이 JSON 표현을 반환한다.
'{"name":"John", "age":30}'
3) 헤더
응답에는 응답에 대한 헤더 또는 메타데이터도 포함된다. 이는 응답에 대한 추가 컨텍스트를 제공하고 서버, 인코딩, 날짜 및 콘텐츠 유형과 같은 정보를 포함한다.
4) AWS 컴퓨터 네트워킹 다음 단계
제품 관련 추가 리소스 확인 -> 무료 계정에 가입 -> 콘솔에서 구축 시작
package.json
package.json이란 현재 프로젝트에 관한 정보와 패키지 매니저(npm, yarn)을 통해 설치한 모듈들의 의존성을 관리하는 파일이다.
1. package.json의 기본 정보
기본 정보란 package.json을 자동으로 생성할 때(npm init), -y를 명령어를 붙이지 않은 경우 입력하게 되는 것들을 나타낸다.
name, version, description, author, license 등을 입력할 수 있는데, 프로젝트에 대한 간략한 내용을 입력할 수 있다. 처음 생성할 때 입력하지 않은 경우에 추후에 package.json을 변경하여 입력할 수 있다.
2. package.json 사용이유
만약 이 package.json 파일을 사용하지 않을 경우 다음과 같은 문제가 발생할 수 있다.
프로젝트에서 사용하는 외부 모듈들이 많아지게 되면 관리하기가 어려워진다. 각 패키지들은 고유한 버전이 있고, 패키지의 버전도 빈번하게 업데이트가 되기 때문에 따로 기록해 두어야 한다. 새로운 프로젝트를 진행할 때 필요한 모듈들이 많다면 매번 npm 명령으로 설치해야 하는 번거로움이 있다.
이런 경우 필요한 패키지들의 목록을 파일로 정리해놓고, 목록 파일을 이용하여 단 한번의 명령어로 필요한 패키지들을 모두 설치할 수 있다. 이러한 패키지 정의 파일을 package.json 파일이라고 한다. 즉, package.json은 프로젝트에 대한 메타정보, 그리고 설치한 패키지의 의존성 및 버전을 관리하는 파일이다.
vue cli로 Vue 프로젝트를 생성하면, 자동으로 package.json 파일이 만들어 지지만, npm init을 사용하면 package.json 파일을 직접 만들 수도 있다. 그리고 팀 내에서 동일한 개발환경을 구축하려고 할 때 이미 작성된 package.json 파일이 있다면 팀 내에 배포하여 동일한 개발환경을 빠르게 구축할 수 있다.
[내 이야기]
1주차 2주차도 막막했지만 가면 갈 수록 더 막막하다...
이번이 진짜 제일 막막했다. 아무것도 모르는 상태(?)에서 시작하려니 뭐부터 시작해야 하는지도 모르겠다. 이것이 무에서 유로 만들어라 이런건가.. 뼈대만드는 것 부터 힘들었다. 그래도 뼈대만들면 반이라도 한 것 같은 느낌이 나기 때문에.. (개인차입니다.) 열심히 했다.
반 사람들이 이해만 한다면 금방 만들 수 있다고 해서 일단 이해 할려고 노력부터 했다. 반 사람들이 와서 도와줄려고 했지만, 여기서 코드보여주고 하라는대로 하라고 한다면 실력이 늘 것 같지 않아 하룻동안은 아무랑도 말 하지 않고 혼자 묵묵히 했다. (게더 켜놓고 잠수모드..)
덕분에 그 하루 동안 머릿속에 그림이(?) 그려지면서 나름 완성을 하고, 작동 안되는거 2가지 문제를 들고 우리 팀 에이스님을 찾아가 코드를 보여주고 물었다. 내 코드가 잘 못 된건지,, 어느 부분 코드가 잘 못된건지 한 줄 한 줄 고치며 계속 썬더 클라이언트 돌리다가 찾아냈다. 결국 왜 틀린지는 모르겠지만 우리팀 에이스 코드를 받아 1줄 바꿔넣으니까 작동됐다. 너무 감사했다 ㅠㅠ,,,
진짜 하차할까란 생각도 들고, 나랑 맞지 않은건가 생각도 들었는데 오기가 생겨버려서 1시간 혼자 패닉에 빠지다가 '될대로 되라 완성만 한다' 라는 마인드를 가지고 응하니 나름 멘탈도 괜찮아 지고 코드도 잘 짜지게 됐다. 다음 주차도 편안한 마음가짐으로 코드짜야겠다.
끝~~
