202.05.30 WIL - REST API, JSON, 회고록

Seong Hyeon Kim·2022년 5월 29일

WIL

목록 보기

4/6

Json

package.json이란?
package.json이란 현재 프로젝트에 관한 정보와 패키지 매니저(npm, yarn)을 통해 설치한 모듈들의 의존성을 관리하는 파일이다.

{
  "name": "tutorial",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

이름처럼 JSON 포맷으로 이루어져 있다.

생성방법

npm init // 프로젝트명, 설명 등 작성할 내용이 있을 경우
npm init -y // 입력할 내용없이 package.json 생성


yarn init
yarn init -y

package.json의 기본 정보

기본 정보란 package.json을 자동으로 생성할 때(npm init), -y를 명령어를 붙이지 않은 경우 입력하게 되는 것들을 나타낸다.

name, version, description, author, license 등을 입력할 수 있는데, 프로젝트에 대한 간략한 내용을 입력할 수 있다. 처음 생성할 때 입력하지 않은 경우에 추후에 package.json을 변경하여 입력할 수 있다.

버전관리
의존성 모듈을 설치하게 되면 dependencies안에 해당 모듈의 버전과 이름이 추가된다.

{
  "name": "tutorial",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "dependencies": {
    "react": "^17.0.2", // react 설치 결과
  },
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

의존성 모듈 설치
package.json은 의존성을 모듈을 관리하는 하나의 파일이다. 즉, 모듈들이 차곡차곡 쌓일 수록 dependencies에는 다양한 내용들이 추가된다. 이 파일 하나로 프로젝트에 필요한 모듈들을 한번에 설치할 수 있다.

npm install

여기까지가 기본적인 형태와 설명들이고

보다 자세한 설명은 https://hoya-kim.github.io/2021/09/14/package-json/ 여기를 참고하면 더 상세하게 나와있습니다.

REST API

REST API란 REST를 기반으로 만들어진 API를 의미합니다. REST API를 알기 위해 REST부터 알아보도록 하겠습니다.

REST 란

REST(Representational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.

즉 REST란

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE)를 통해
해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

CRUD Operation이란
- CRUD는 대부분의 컴퓨터 소프트웨어가 가지는 기본적인 데이터 처리 기능인 Create(생성), Read(읽기), Update(갱신), Delete(삭제)를 묶어서 일컫는 말로
  REST에서의 CRUD Operation 동작 예시는 다음과 같다.

Create : 데이터 생성(POST)
Read : 데이터 조회(GET)
Update : 데이터 수정(PUT)
Delete : 데이터 삭제(DELETE)

* REST 구성 요소

REST는 다음과 같은 3가지로 구성이 되어있다.

자원(Resource) : HTTP URI

자원에 대한 행위(Verb) : HTTP Method

자원에 대한 행위의 내용 (Representations) : HTTP Message Pay Load

REST의 특징

Server-Client(서버-클라이언트 구조)

Stateless(무상태)

Cacheable(캐시 처리 가능)

Layered System(계층화)

Uniform Interface(인터페이스 일관성)

## REST의 장단점

장점

HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
Hypermedia API의 기본을 충실히 지키면서 범용성을 보장한다.
REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
서버와 클라이언트의 역할을 명확하게 분리한다.

단점

표준이 자체가 존재하지 않아 정의가 필요하다.
사용할 수 있는 메소드가 4가지밖에 없다.
HTTP Method 형태가 제한적이다.
브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 정보의 값을 처리해야 하므로 전문성이 요구된다.
구형 브라우저에서 호환이 되지 않아 지원해주지 못하는 동작이 많다.(익스폴로어)

RESPT API란 REST의 원리를 따르는 API를 의미합니다.

하지만 REST API를 올바르게 설계하기 위해서는 지켜야 하는 몇가지 규칙이 있으며 해당 규칙을 알아 보겠습니다.

REST API 설계 예시

URI는 동사보다는 명사를, 대문자보다는 소문자를 사용하여야 한다.
마지막에 슬래시 (/)를 포함하지 않는다.
언더바 대신 하이폰을 사용한다.
파일확장자는 URI에 포함하지 않는다.
행위를 포함하지 않는다.

회고록

* Chapter 3에서 스스로 가장 많이 성장했다고 느낀 부분이 있다면 자유롭게 적어주세요

- 항해톡을 준비하며..

#1
프로세스 와 스레드 사실 살면서 처음들어보는 단어인데, 이것에 관해서 조사를 해서 설명을 하고 발표를 하라니
내 스스로 생각해도 너무 대책없이 나간건 아닌가 하는 생각이 들었다.

하지만 이걸 준비하면서 스스로가 더욱 성장할 수 있다라는 생각에 지원했던 만큼 안하려면 안했지 기왕한거 멋지게 하자는 생각에 열심히 준비했던 것 같다.

회사 생활을 할때 내가 후배 사원들을 가르칠 때 느꼇던 것중 가장 큰 요소는 내가 스스로 알지 못하면 가르치지 못한다는 점이였고, 내가 안다고 해서 상대방도 그것을 무조건 알아들으라는 법은 없다는 것이였다.

즉, 내가 제대로 알지 못하면 제대로 설명할 수 없고, 그것은 제대로 알고 있는 것이 아니였다.

#2
그래서 항해톡을 준비하며 우선은 내 스스로가 이해하려고 더 노력했던 것 같다.
그 다음은 내가 이해한 것을 어떻게 하면 쉽게 설명할 수 있을까 였다.
짧은 시간에 이해하려다보니 깊게 이해하기보다는 조금은 가볍게 이해하고 있어서 설명에 어려움이 있던 찰나
역시나 뭐가 안될때는 구글링이 답이였다.

너무나 좋은 예시로 설명해준 부분들을 참고하면서 나의 발표를 듣는 모든 사람들이 나처럼 힘들게 아는게 아니라 쉽게 이해하길 바랬고, 다행히도 그런 나의 의도가 잘 전달된거 같아서 너무 기뻣다.

#3
약간의 핑계를 대자면 항해톡에 집중하느라 개인과제에 힘을 못쓴게 조금 아쉽긴 하지만, 그래도 이것을 하면서 확실히 얻어가는게 더 많았다고 생각한다.

내가 설명 못하는 것은 확실히 알지 못하는 것이다.

라는 게 이번주의 핵심인것 같다.

* Chapter 3에서 스스로 더 많이 성장하기 위해, 어떤 노력을 더 할 수 있었을까요?

- 메타인지란?

- 쉽게 말하면 **자신이 무엇을 알고 무엇을 모르는지 아는 것을 의미합니다.**
- 프로젝트에 돌입하기 자신의 강점, 보완점을 꾸준히 파악하고 이에 따른 학습을 계획합시다!

이번 주특기 1주차를 마치면서 내가 가장 중요하게 생각해야될 요소는 아마도 이 메타인지 인것 같다. 위의 제목처럼 내가 무엇을 알고 무엇을 모르는지가 아닌 내가 어떤것을 알아야 하는지에대한 고민을 해봐야 하는 시간인 것 같았다.

#1
우선 이번주차의 나의 가장 큰 실수는 내가 해야될 정확히는 이번주의 해야될 과제 내용을 정확히 파악하지 않은채 이해하겠다는 생각으로 강의만 주구장창 본게 나의 가장 큰 잘못인 것 같다.

내가 해야될 과제 구체적으로는 내가 어떠한 것을 해내야 되는지를 정확히 파악하지 못한 채 나 스스로 강의를 이해하고 그 내용을 토대로 무언가를 만들면 되지 라는 안일한 생각이 이번주의 가장 큰 실수인 것 같다.

심지어 그것조차도 내가 완전히 이해하고 새롭게 만들 생각은 못한채 내가 이해할 수 있는 부분은 한정적이니깐 우선 기존 과제를 조금 수정해서 만들어야지 라는 오만한 생각까지 했다는게 너무 괘씸하다.

그래놓고 이렇게 따라만 해서 내가 나중에도 잘할 수 있을까 하는 의문을 들었다는게 더더욱 충격인것 같다.

마치 이길이 아닌것 같은데 하는 하면서도 그 길로 가는 길치들의 전형적인 특성처럼, 내 스스로가 나를 잘못된 길로 가게하고 있던 건 아니였나 하는 생각이 들었다.

사람이 사람한테 할 수 있는 가장 나쁜 짓은 상대방의 단점을 보고도 지적하지 않는것이다.

누군가에게는 오지랖일수도 있지만 누군가에게는 인생이 바뀔수도 있는 것이 바로 그 사람의 단점을 말해주는것이라고 생각한다. 잘못된 길로 가서 낭떠러지로 가고 있어도 그걸 말해주지 않는다면 살인 방조죄나 다름 없듯
단점을 지적한다는 것은 어떻게 받아들이냐에 따라서 누군가의 인생이 바뀔수도 있는 문제이다.

그래서 단점을 보고도 말해주지 않는게 사람이 할 수 있는 가장 나쁜짓이라고 하는건데, 나는 나 스스로에게 그렇게 하고있었다.

모르는게 있으면 부족한게 있으면 그것을 알고 넘어갈 생각을 해야하는데 지금은 일단 해야하니깐, 지금은 어떻게든 넘기고 나중에 보충하면 되지, 라는 안일한 생각이 나를 점점 더 깊이감 없는 개발자로 바꿔나가고 있었던 것 같다.

과거 회고록에서 적었듯 나는 내가 부족한 것을 알면서도 그것을 고치려하지 않는 나쁜 버릇이 있었는데, 이번것도 그것의 연장선 인것 같다.

그래도 난 다행인지 좋은 사람들을 많이 만나서, 나의 단점을 나의 부족한 것들을 채워줄 수 있는 사람들을 만나서 조금의 변화는 있을 것 같다.

최경식 매니저님이 가르쳐준

해야될 일(목표) 먼저 확인 후 어떻게 할 것인지, 혹은 어떻게 구현할 수 있는지를 생각하고 조사하고 파악한 후(구글링) 강의내용에서 원하는 부분을 중점적으로 보는게 좋습니다

라는 피드백은 남은 2주차 역시 힘들겠지만 어떻게 생각하고 행동해야 될지를 알게된 것 같아서 기뻤고,

이번주차의 같은조원인 성현님과 진우님에게

그전에는 했던 것을 수정만 하면서 했었지만, 그렇게 하면 결국 내가 모르는 채로 하게 되는 거고, 그러면 어찌어찌 할수는 있지만 깊이가 없는 개발자가 될 수 있으니 반드시 익히고 넘어가는게 좋습니다.

라는 피드백 역시 나의 단점을 지적하면서 내가 어떻게 해야될지를 짚어주는 피드백이여서 너무나 도움이 되었다.

확실히 개인적인 이유로 스스로가 너무 조급해하며 배웠던 것도 있는 것 같다. 힘들겠지만 조급함을 내려놓고
배움으로써 생기는 무지에 대한 두려움을 떨쳐내는 기쁨을 좀더 생각해야 겠다.

그리고 위에 적어놨던 것처럼 내가 스스로 알지 못하면 그것은 할줄 아는게 아니고, 자꾸 미루고 미루고 하면 결국 나는 미루기만 할 줄 아는 개발자가 될 것이기 때문에, 나의 이 단점들을 극복하기 위해 기술적인 TIL 도 좀 써가면서 내가 못하는것만이 아닌 내가 잘하고 할줄 알게 되는것을 좀더 가꿔야겠다는 생각이 든 한주차 였따.