개발 회고록

항해99 회고 일지 3주차

hovinee 2022. 1. 30. 22:04

이번 3주차 역시 시간이 금방 지나갔다. 이번주차는 평점만들기를 끝내고 리덕스와 미들웨어를 배우는 주간이다. 나만의 사전을 만들기 위해 기능을 구현했는데 리덕스에 Create, Upadte, Delete를 활용하여 input에 글을 넣고 추가하기를 누르면 메인페이지에 카드 모양으로 단어장 형태의 글이 나오고 카드 하나하나에 수정, 삭제의 기능을 구현하였다. 대략적인 루트는 dispatch를 통하여 원하는 기능을 리덕스로 보내고 타입을 만들어 실질적으로 리듀서에서 액션을 실행하여 넘겨준다.

그다음은 css를 공부하였다. 대략적으로 어떤 기능을 하는지에 대하여 알고는 있었지만 깊게 파고들어 본적이 없어서 공부를 하였다. 원했던 기능은 카드 상자를 간격에 맞춰 잘 나열하고 싶었는데 flex와 grid 기능의 내용을 보고 이해할 수 있었다. 하지만 아직 부족한 점이 많고 keyframes을 쓰는 방법도 잘 몰라 기능 구현을 할때 알맞는 css를 쓸 수 있도록 계속적으로 다듬어 가야겠다. 

 

1. RESTful API란?

RESTful API라는 단어에서 사용되는 REST(REpresentational State Transfer)의 개념을 한줄로 정의하자면 아래와 같이 정의할 수 있습니다.

 

       HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식

 

즉, REST란 어떤 자원에 대해 CRUD(Create, Read, Update, Delete) 연산을 수행하기 위해 URI(Resource)로 요청을 보내는 것으로, Get, Post 등의 방식(Method)을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)으로 표현됩니다. 그리고 이러한 REST 기반의 API를 웹으로 구현한 것이 RESTful API인데 예를 들어, 우리는 게시글을 작성하기 위해 http://localhost:8080/board
라는 URI에 POST방식을 사용하여 JSON형태의 데이터를 전달할 수 있습니다. 위와 같이 CRUD 연산에 대한 요청을 할 때, 요청을 위한 Resource(자원, URI)와 이에 대한 Method(행위, POST) 그리고 Representation of Resource(자원의 형태, JSON)을 사용하면 표현이 명확해지므로 이를 REST라 하며, 이러한 규칙을 지켜서 설계된 API를 Rest API 또는 Restful한 API라고 합니다. 그리고 위에서 살짝 언급하였듯이, 이러한 Rest API는 Resource(자원), Method(행위), Representation of Resource(자원의 형태)로 구성됩니다.


출처: https://mangkyu.tistory.com/46 [MangKyu's Diary]

package.json?

  • package.json 파일은 배포한 모듈 정보를 담고자 만들어졌다.
  • pacakge.json 파일은 기본적으로 CommonJS의 명세를 충실히 따르고 있으며 JSON 형식의 파일이다.
  • 직접 작성할 수도 있고 npm init 명령을 통해서 자동으로 생성할 수도 있다.
{
	"name" : "test",
	"description" : "javascript's test programming.",
	"keywords" : ["util", "f", "server", "client", "browser"],
	"author" : "Goorm",
	"contributors" : [],
	"dependencies" : [],
	"repository" : {"type": "git", "url" : "git://gitbub.com/documentcloud/test.git" },
	"main" : "test.js",
	"version" : "1.1.6"
}

name

  • 프로젝트 이름으로, 가장 중요하다. 중앙 저장소에 배포할 때 version과 함께 필수 항목이다.
  • url로 사용되고, 설치할 때 디렉토리 이름이 되기 때문에 url이나 디렉터리에서 쓸 수 없는 이름을 사용하면 안 된다.
  • 또한, 이름에 node나 js가 들어가면 안 된다.
  • name은 214자보다 짧아야 하며, 점(.)이나 밑줄(_)로 시작할 수 없다.
  • 대문자를 포함해서는 안 되며, require() 함수의 인수로 사용되며 짧고 알기 쉬운 것으로 짓는 것이 좋다.

version

  • 프로젝트 버전을 정의힌다. 3단계 버전을 사용하며, - 로 태그 이름을 적을 수 있다.

description

  • 프로젝트 설명으로, 문자열로 기술한다.
  • npm search로 검색된 리스트에 표시되기 때문에 사람들이 패키지를 찾아내고 이해하는 데 도움이 된다.

keywords

  • 프로젝트를 검색할 때 참조되는 키워드이다.
  • description과 마찬가지로 npm search로 검색된 리스트에 표시된다.

homepage

  • 프로젝트 홈페이지 주소이다.
  • url 항목과는 다르며, url을 설정하면 예상치 못한 움직임을 하게 되므로 주의한다.

author

  • 프로젝트 작성자 정보로, 한 사람만을 지정한다. JSON 형식으로 name, email, url 옵션을 포함한다.

contributors

  • 프로젝트에 참여한 공헌자 정보로, 여러 사람을 배열로 지정할 수 있다.

repository

  • 프로젝트의 소스 코드를 저장한 저장소의 정보이다.
  • 소스 코드에 참여하고자 하는 사람들에게 도움이 될 수 있다. 프로젝트의 홈페이지 url을 명시해서는 안 된다.

scripts

  • 프로젝트에서 자주 실행해야 하는 명령어를 scripts로 작성해두면 npm 명령어로 실행 가능하다.
"scripts": {"start": "node server.js"}

config

  • 소스 코드에서 config 필드에 있는 값을 환경 변수처럼 사용할 수 있다.
"name": "foo",
"config": {
    "port": "8080"
}

private

  • 이 값을 true로 작성하면 중앙 저장소로 저장하지 않는다.

dependencies

  • 프로젝트 의존성 관리를 위한 부분이다. 이 프로젝트가 어떤 확장 모듈을 요구하는지 정리할 수 있다.
  • 일반적으로 package.json에서 가장 많은 정보가 입력되는 곳이다.
    애플리케이션을 설치할 때 이 내용을 참조하여 필요한 확장 모듈을 자동으로 설치한다.
    따라서 개발한 애플리케이션이 특정한 확장 모듈을 사용한다면 여기에 꼭 명시를 해주어야 한다.
  • 또한, npm install 명령은 여기에 포함된 모든 확장 모듈들을 설치하게 되어 있다.

devDependencies

  • 개발할 때만 의존하는 확장 모듈을 관리한다.

engine

  • 실행 가능한 노드 버전의 범위를 결정한다.