자바스크립트에서 유사배열과 배열의 차이는 무엇일까요? 유사배열의 각 요소를 수정하고 싶다면 어떤 과정을 거쳐야 할까요?
- 일반적으로 자료구조에서의 배열은 '연속된 메모리 공간에 나열된 동일한 타입의 데이터(요소)들의 집합'
- JavaScript에서 배열은 이러한 배열의 특징을 흉내내고 있는 아주 특수한 객체. typeof []; // 'object'
- 일반적인 자료구조에서의 배열은 동일한 타입의 원소만 가질 수 있지만, js에서 배열은 다양한 타입의 프로퍼티를 가질 수 있음.
- JS에서 배열은 index를 key로 프로퍼티 값에 접근할 수 있고, length라는 프로퍼티를 갖고 있는 특수한 객체.
- 객체와 배열의 가장 큰 차이점은, 배열의 각 요소 간에는 순서가 있음.
- 유사 배열 객체는 배열처럼 보이지만 index로된 프로퍼티 키들과 length가 있는 객체라는 점만 같음.
- Argument 객체와 DOM에서 요소를 가져올 때 NodeList의 경우도 유사 배열 객체.
- 유사배열객체에서는 map, reduce, filter 같은 Array.prototype에 있는 빌트인 메소드가 없음.
- 유사배열객체는 순회가능한 이터러블 객체가 아님. 하지만 Array.from 메소드를 사용하면 유사배열객체를 배열로 변환해 map 등의 메소드를 사용하거나 순회할 수 있음.
RESTful API란 무엇일까요?
- REST API 는 오늘날 웹에서 볼 수 있는 가장 많이 사용되고 유연한 API. 클라이언트가 서버에 요청을 데이터로 전송하고 서버가 이 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환. REST는 Representational State Transfer의 줄임말로, 클라이언트가 서버 데이터에 액세스하는 데 사용할 수 있는 GET, PUT, DELETE 등의 함수 집합을 정의. 클라이언트와 서버는 HTTP를 사용하여 데이터를 교환. (참고 https://aws.amazon.com/ko/what-is/api/)
REST 의 특징
- Uniform (유니폼 인터페이스)
- Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일.
- Stateless (무상태성)
- REST는 무상태성 성격. 작업을 위한 상태정보를 따로 저장하고 관리하지 않음. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순.
- Cacheable (캐시 가능)
- REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능. 따라서 HTTP가 가진 캐싱 기능이 적용 가능. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능.
- Self-descriptiveness (자체 표현 구조)
- REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것.
- Client - Server 구조
- REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됨.
- 계층형 구조
- REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 함.
<팀원들이랑 정리한 RESTful API>
-
REST라는 개념은 로이 필딩이라는 HTTP 저자 중 한 사람이 발표한 개념으로 당시 웹 설계의 우수성에 비해 제대로 사용되어지지 모습을 보면서 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다.
-
쉽게 정리하자면 로이 필딩이라는 사람이 현재 사용되고 있는 API가 규격 없이 사용되는 것 같아서 모두가 같이 이해할 수 있는 API 프로토콜을 만들었고, 무조건 그 규격을 따라야 하는 것은 아니지만 현재는 보편화가 되어서 모두가 이 개념 아래 API를 사용하고 있다고 생각하면 된다. 그렇기에 RESTful하게 사용하자고 권장하는 것이다.
-
REST API의 특징들은 다음과 같다.
-
클라이언트-서버 아키텍처: 클라이언트, 서버, 리소스로 구성된 REST 아키텍처이며 HTTP를 통해 요청을 처리합니다.
-
스테이트리스(Statelessness): 요청 후 다음 요청이 있을 때까지 클라이언트 콘텐츠가 서버에 저장되지 않으며 그 대신 세션 상태에 대한 정보가 클라이언트에 저장됩니다.
-
캐시 가능성: 캐싱으로 일부 클라이언트-서버 간 상호 작용을 대신할 수 있습니다.
-
계층화된 시스템: 추가 계층으로 클라이언트-서버 간의 상호 작용을 조정할 수 있으며 이러한 계층은 로드 밸런싱, 공유 캐시 또는 보안과 같은 추가 기능을 제공할 수 있습니다.
-
자체 표현 구조(Self-descriptiveness): REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체표현구조로 되어 있습니다.
-
-
즉 RESTful 이라는 것은 이러한 특징들이 다 지켜지는 것은 아니어도 안정적이고 보편적이며 신뢰 할만한가를 잘 준수하고 있느냐를 말하는 것이다.
-
API 란?? (Application Programming Interface)
-
애플리케이션 프로그래밍 인터페이스. 정의하자면 애플리케이션 소프트웨어를 구축하고 통합하는 정의 및 프로토콜 세트이다. 때때로 API는 정보 제공자와 정보 사용자 간의 계약으로 지칭되며 소비자에게 필요한 콘텐츠(호출)와 생산자에게 필요한 콘텐츠(응답)를 구성한다.
-
예를 들어 날씨 서비스용 API에서는 사용자는 우편번호를 제공하고, 생산자는 두 부분(첫 번째는 최고 기온, 두 번째는 최저 기온)으로 구성된 응답으로 답하도록 지정할 수 있다. 즉, 컴퓨터나 시스템과 상호 작용하여 정보를 검색하거나 기능을 수행하고자 할 때 API는 사용자가 원하는 것을 시스템에 전달할 수 있게 지원하여 시스템이 이 요청을 이해하고 이행하도록 할 수 있다.
-
종합 RESTful 한 API 란 , REST 라는 개념을 원칙으로 한 애플리케이션 프로그래밍 인터페이스라 할 수 있겠다.