LinkedList
연결 리스트는 여러 자료를 저장하기 위한 자료구조의 일종으로
자료를 저장할 때 다음 자료의 위치를 같이 저장한다.
가장 기본적인 연결 리스트는 데이터를 저장하기 위한 노드들과
첫번째 노드를 가리키기 위한 필드로 이뤄져 있다.
노드는 데이터를 저장하는 데이터 필드와, 다음 노드의 위치를 저장하기 위한 링크 필드를 갖고 있다.
private static class Node {
private int data; // 자료 저장
private Node link; // 다음 자료의 위치 저장
}
add
public void add(int data) {
// 1. start == null (LinkedList가 비어있을 때)
if (start == null) start = new Node(data);
// 2. 아니라면 link가 null인 노드가 나올 때까지
else {
Node head = start;
while (head.link != null) {
head = head.link;
}
// while이 끝났을 때, head.link == null이다. (마지막 노드이다)
head.link = new Node(data);
}
}
remove
public int remove(int idx) {
if (idx == 0) {
int value = start.data;
start = start.link;
return value;
}
else {
// 0이 아닐 때
int i = 0;
Node head = start;
Node prev = start;
while (i < idx) {
prev = head;
head = head.link;
i++;
}
prev.link = head.link; //prev.link에 빠질 애가 갖고 있던 link를 넘겨줌.
return head.data;
}
}
연결 리스트는 데이터를 추가, 제거가 빈번할 경우 유리하다.
데이터를 중간에 추가할 경우
ArrayList 같은 경우는 중간에 추가된 데이터의 뒤에 있던 모든 데이터를 한칸 뒤로 옮겨야하지만
LinkedList는 새 노드 생성 후 삽입할 위치의 전에 있던 노드의 link에 새 노드를 할당 후
새 노드의 link에 본래의 link에 있던 노드를 할당하면 된다.
그러나 인덱스를 통해 접근할 수는 없다는 단점이 있다.
데이터 추가, 제거가 빈번하면 --> LinkedList
데이터의 위치 기반한 조회가 빈번하면 --> ArrayList
직렬화 Serialization
직렬화란 메모리상에 저장된 데이터를 전송 가능한 형태로 바꾸는 작업을 말한다.
눈으로 확인할 수 있는, 해석 가능한 형태로 바꾸는 것이다.
반대로 어떤 객체나 자료 구조의 형태를 직렬화된 데이터로부터 유추해서
다시 메모리 상에서 활용 가능한 형태로 재해석하는 과정을 역직렬화라고 한다.
REST
REST는 HTTP를 이용한 서버를 구현할 때 지켜야 하는 설계 원칙이다.
어떤 서버가 받을 수 있는 요청의 형태와 그에 따른 응답이 어떤 형태로 만들어져야 하는지에 대한 제약사항들을 말한다.
REST의 6가지 원칙
1. Client - Server Architecture
클라이언트와 서버의 분리.
서버는 데이터가 어떤 방식으로 표현되는지 몰라도 된다.
마찬가지로 클라이언트로 데이터가 어떻게 저장되는지 알 필요가 없다.
이 원칙을 통해 서버와 클라이언트는 서로 독립적으로 발전할 수 있다.
2. Statelessness
상태를 저장하지 않는다는 의미.
클라이언트가 보내는 요청이 독립적으로 동작할 수 있도록 구성해야 한다는 뜻이다.
클라이언트가 보내는 개별적인 요청은 서버가 해당 요청을 이해하는데 충분한 정보를 포함해
서버가 이전에 보내진 요청에 대한 정보를 저장할 필요가 없어야 된다는 제약사항이다.
3. Cacheability
인터넷에서 클라이언트는 응답을 캐시에 저장해 두는 경우가 존재하는데
이때 서버에서 보내주는 응답은 클라이언트에게 그 응답이 캐싱이 가능한 응답인지를 표현해주어야 한다는 제약사항이다.
이를 통해 같은 요청을 했을 때 데이터를 받아오는 속도를 감소시킬 수 있다.
4. Layered System
클라이언트가 어떤 서버에 요청이 도달하기까지의 상세한 과정에 대해 알 필요가 없어야 한다는 제약사항.
사용자가 많은 서비스의 경우 부수적인 서버를 구축하는 경우가 있는데
클라이언트는 이런 구조에 대해 알 필요가 없는 뜻이다.
클라이언트가 서버에 요청이 도달하기까지의 과정을 알 필요가 없고, 영향 받지도 않아야 한다!
5. Code on Demand (Optional)
실행 가능한 코드를 전달함으로써 일시적으로 클라이언트의 기능을 확장할 수 있어야 한다는 제약사항.
optional이라 필수는 아님.
6. Uniform Interface
REST에서 가장 근본적으로 여기는 제약사항으로, RESTful API가 가지는 인터페이스를 묘사한 내용이다.
서버가 요청을 받는 형식에 있어서 일관된 인터페이슬르 유지함으로써 클라이언트와 서버가 독립적으로 발전할 가능성을 만들도록 해야 한다는 제약사항이다.
Unifor Interface의 부원칙들
- 서버에 요청하고 있는 자원이 요청 자체로 식별이 되어야 한다.
- 자원에 대해 조작을 할 때, 그 자원의 상태나 표현으로 조작이 가능해야 한다.
- 각 요청과 응답은 자기 자신을 해석하기 위한 충분한 정보를 포함해야 한다.
- HAETOAS
'멋쟁이 사자처럼 > TIL' 카테고리의 다른 글
230627 11주 2일차 TIL. 관점 지향 프로그래밍 AOP (0) | 2023.06.27 |
---|---|
230626 11주 1일차 TIL. 그래프, Validation, (0) | 2023.06.26 |
230619 10주 1일차 TIL. Queue, HTTP (0) | 2023.06.19 |
230615 9주 4일차 TIL. JPA 복습, create, readAll (0) | 2023.06.18 |
230614 TIL. Spring Streotypes (Beans) (0) | 2023.06.14 |