• 쉽게 비유를 들어서 위의 그림으로 설명 가능
• 손님과 요리사 사이에서 점원의 역할이 프로그램과 프로그램 사이의 API 역할이라고 생각하면 됨
• 즉, 프로그램간의 요청을 편리하게 처리하기 위해 존재한다.

Application Program Interface ( API )의 사전적 정의

프로그램을 작성하기 위한 일련의 부(Sub) 프로그램, 프로토콜 등을 정의하여 상호 작용을 하기 위한 인터페이스 사양

2. REST API (RESTful API)

1) REST API 란?

REST ( Representational State Transfer )

• 표현 가능한 상태에서의 전달 ( 직역 )

• 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미
• REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

2) REST API 설계 기본 규칙

• URI는 정보의 자원을 표현해야 한다.
• 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE 등)로 표현한다.
  • URI에 HTTP Method가 들어가면 안된다.
    • Ex) GET /members/delete/1 -> DELETE /members/1
  • 경로 부분 중 변하는 부분은 유일한 값으로 대체한다.(즉, :id는 하나의 특정 resource를 나타내는 고유값이다.)

        Ex) student를 생성하는 route: POST /students
        Ex) id=12인 student를 삭제하는 route: DELETE /students/12

3) REST API 설계 규칙

1. 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다.
   • Ex) http://restapi.example.com/houses/apartments

2. URI 마지막 문자로 슬래시(/ )를 포함하지 않는다.

   • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다.
   • REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
   • Ex) http://restapi.example.com/houses/apartments/ (X)

3. 하이픈(- )은 URI 가독성을 높이는데 사용

   • 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.

4. 밑줄(_ )은 URI에 사용하지 않는다.

5. URI 경로에는 소문자가 적합하다.

6. 파일확장자는 URI에 포함하지 않는다.

7. 리소스 간에는 연관 관계가 있는 경우

   • /리소스명/리소스 ID/관계가 있는 다른 리소스명
   • Ex) GET : /users/{userid}/devices(일반적으로 소유 ‘has’의 관계를 표현할 때)

• End to End 프로젝트

• 3계층에 대한 이해

• API 설계하기 (CRUD) 와 구현

2. Repository 만들기

1) Memo 클래스 만들기

왜 필요할가? Memo라는 것을 구현하려면 필요한 Table을 만들어야 함 → 이러한 기능을 Repository에서 domain이 담당하게됨 → domain > Memo.java 클래스를 만들어 준다.

• 메모는 1) 익명의 작성자 이름(username), 2) 메모내용(contents)로 이루어져 있다.
• Memo.java

    @NoArgsConstructor // 기본생성자를 만듭니다.
    @Getter // getter를 lombok으로 쉽게 표현
    @Entity // 테이블과 연계됨을 스프링에게 알려줍니다. DB설계도로 할거야를 알려줌
    public class Memo extends Timestamped { // 생성,수정 시간을 자동으로 만들어줍니다.
    // Timestamped를 상속받아 기능을 추가(생성시간, 수정시간 변수화)

        @GeneratedValue(strategy = GenerationType.AUTO) // 1씩 증가하게 자동생성
        @Id // Primary key를 지정
        private Long id;                // 인스턴스 변수 1

        @Column(nullable = false)
        private String username;        // 인스턴스 변수 2

        @Column(nullable = false)
        private String contents;        // 인스턴스 변수 3

        public Memo(String username, String contents) { // 생성자를 만들어줌
            this.username = username; // 기본 생성자가 필요하지만 어노테이션 처리함
            this.contents = contents;
        }

        public Memo(MemoRequestDto requestDto) {
            this.username = requestDto.getUsername();
            this.contents = requestDto.getContents();
        }

        public void update(MemoRequestDto requestDto){ // 업데이트 메소드
            this.username = requestDto.getUsername();  // return 없음
            this.contents = requestDto.getContents();  // DTO를 통해서 update하게 됨
        }

    }

- DB를 직접 바꿀일은 없으므로 Setter는 필요 없음, Getter만 필요
- record를 생성할때 정해진 파라미터가 필요하므로 생성자가 필요함
- requestsDto를 통해서 데이터를 이동시키므로 생성자의 파라미터 타입 MemoRequestDto

2) MemoRepository 인터페이스 만들기

왜 필요할가? SQL과 같은 기능을 하는 것은 Repository 따라서 MemoRepository를 만들어 줌 이때 JpaRepository의 메서드만 사용할 것이므로 상속후 인터페이스로 만들어 줌

• MemoRepository.java

    public interface MemoRepository extends JpaRepository<Memo, Long> { // 상속 후 JPA 메서드 사용
        List<Memo> findAllByOrderByModifiedAtDesc(); // 수정시간 기준 오름차순으로 List안에 Memo 객체를 넣어줌
    }

- JPA 메서드만을 사용하는 인터페이스를 만드는데 Memo DB이므로 MemoRepository를 만듬

3) MemoRequestDto 클래스 만들기

왜 필요할가? DB에 직접 접근하여 값을 수정하는 것은 데이터 분석에도 금기 되어 있는 사실! 따라서 값의 이동이 있을 때 DTO를 사용

• MemoRequestDto.java

    @Getter
    public class MemoRequestDto {
        private String username;     // 컬럼 중 하나
        private String contents;     // 컬럼 중 하나

    }

- 자동생성되는 ID는 제외하고 memo table의 column을 멤버 변수로 갖는다.
- 또한 private 멤버 변수를 조회하기 위해 Getter 옵션을 사용한다.

3. MemoService 클래스 만들기

왜 필요할가? 일단은 Client에서 DB로 넘어가서 update를 해준다는 점에서 Service에 해당이 됨 추후 DB 관련 update는 모두 Service에서 구현하는지 궁금함 또한, 서비스에 대한 이해가 진짜 필요함

• MemoService.java

    @RequiredArgsConstructor  // final은 꼭 필요한 녀석으로 생성자도 필요로 함
    @Service // Service임을 알려주고 있음
    public class MemoService {

        private final MemoRepository memoRepository;  //꼭 필요한 녀석

        @Transactional // 트랜젝션 기능
        public Long update(Long id, MemoRequestDto requestDto) {
            Memo memo = memoRepository.findById(id).orElseThrow(
                    () -> new IllegalArgumentException("아이디가 존재하지 않습니다.")
            );
            memo.update(requestDto);
            return memo.getId();
        }
    }

- 일단 Client단에서 DB로 데이터의 이동이기 때문에 Service에 update를 만들어 놓는 것임

4. Controller 클래스 만들기

왜 필요할가? API 요청을 처리하기 위해 필요하다. 즉, API 설계도에 따라 적절한 GET, PUT, DELETE, POST에 따라 반환되는 값이 무엇인지 설정해주게 됨

• MemoContoller.java

@RequiredArgsConstructor // final에 꼭 필요한 녀석들은 생성자를 필요로 함
@RestController // Json 형태로 객체 데이터를 반환하기 위함
public class MemoController {

    private final MemoRepository memoRepository; // 꼭 필요한 녀석들을 멤버 변수로 설정
    private final MemoService memoService;

    @PostMapping("/api/memos") // Post요청
    public Memo createMemo(@RequestBody MemoRequestDto requestDto) { // Json으로 입력받으면 
        Memo memo = new Memo(requestDto); // Memo 객체 생성 후
        return memoRepository.save(memo); // DB에 저장
    }

    @GetMapping("/api/memos") // Get 요청
    public List<Memo> getMemos() { // GET이므로 BODY에 json은 없음
        return memoRepository.findAllByOrderByModifiedAtDesc(); // 조회해줌
    }

    @DeleteMapping("/api/memos/{id}")
    public Long deleteMemo(@PathVariable Long id) { //URL path로 부터 파라미터를 받음
        memoRepository.deleteById(id);
        return id;
    }

    @PutMapping ("/api/memos/{id}")
    public Long updateMemo(@PathVariable Long id,@RequestBody MemoRequestDto requestDto){
        memoService.update(id,requestDto); //Service인 update를 이용
        return id;
    }
}

• Client로 부터 시작되는 요청에 따라 어떻게 stack되는지 흐름을 파악할 필요가 있음

• Client 요청으로 부터 해야될 일들이 Controller에 만들어져 있음을 확인

  느낀점!

  1. 객체 지향 개념을 모두 이해하면서 Spring에 대입하는 것이 완벽하게 되지 않는다는 것 (기초가 부족)
  2. 아직도 Service의 모호한 개념이 머리에 있어서 추가 공부가 필요함
  3. Annotation은 그때그때 쓰임새를 알아둘 것
  4. 기본적으로 CRUD를 구현할 자신감은 생김!!

• 80년 초 소프트웨어의 위기 ⇒ 빠른 변화를 못 쫒아감
• 해결책으로 객체지향 언어를 도입 ( 절차적 ⇒ 객체지향 )
• 코드의 재사용성이 높고 유지보수가 용이, 중복 코드 제거
• 프로그래밍 언어 + 객체지향개념 ( 규칙 ) ⇒ 규칙이라서 외워야 함!

  • OOP의 4가지 핵심 개념

  1. 캡슐화
  2. 상속
  3. 추상화
  4. 다형성
• 객체지향 개념은 설계에 해당해서 처음에 하기 힘들다

클래스와 객체

1. 클래스와 객체란?

• 클래스의 정의 : 객체를 정의해 놓은 것
• 클래스의 용도 : 객체를 생성하는데 사용
• 객체의 정의 : 실제로 존재하는 것. 사물 또는 개념
• 객체의 용도 : 객체가 가지고 있는 기능과 속성에 따라 다름

2. 객체의 구성 요소 - 속성과 기능

• 거시적 관점 : 하드웨어를 소프트웨어화(프로그램 화 = 코드) 시키는 것에서 시작
  • 따라서 하드웨어를 분석 & 관찰이 필요함
• 객체 = 속성(변수) + 기능(메서드) ⇒ TV로 예를 들면
  • 속성 : 크기, 길이, 높이, 색상, 볼륨, 채널
  • 기능 : 끄기, 켜기, 볼륨 높이기, 볼륨 낮추기, 채널 변경하기 등등

3. 객체와 인스턴스

• 객체 : 모든 인스턴스를 대표하는 일반적인 용어
• 인스턴스 : 특정 클래스로부터 생성된 객체 ( 예 : TV인스턴스 )
• 객체와 인스턴스는 같은 의미다라고 생각해도 됨
• 클래스 ⇒ 인스턴스(객체) , 인스턴스화 한다라고 표현

Q. 클래스가 왜 필요한가? A. 객체를 생성하기 위해

Q. 객체가 왜 필요한가? A. 객체를 사용하기 위해

Q. 객체를 사용한다는 것은? A. 객체가 가진 속성(변수)과 기능(메서드)을 사용하려고

하나의 소스파일에 여러 클래스 작성

// hello2.java로 소스 파일 이름을 해야함
public class Hello2 {}
       class Hello3 {}

// Hello2.java or Hello3.java 둘다 가능
class Hello2 {}
class Hello3 {}

• java 파일 이름과 Public class 이름과 일치해야 한다.
• 심지어 대소문자도 일치해야 함
• 가능하면 하나의 소스파일에는 하나의 클래스만 작성하는 것이 바람직

객체의 생성과 사용

1. 객체의 생성

*클래스명 변수명; * // 클래스의 객체를 참조하기 위한 참조변수 선언 *변수명 = new 클래스명(); * // 클래스의 객체를 생성 후, 객체의 주소를 참조변수에 저장

//예를 들면
Tv t;             // Tv클래스 타입의 참조변수 t를 선언 (t를 리모콘으로 비유)
t = new Tv();     // Tv인스턴스를 생성한 후, 생성된 Tv 인스턴스의 주소를 t에 저장

//이를 한번에 표현하면
Tv t = new Tv();

2. 객체의 사용

t.channel = 7;     // Tv인스턴스의 멤버변수 channel의 값을 7로 한다.
t.channelDown();   // Tv인스턴스의 메서드 channelDown()을 호출한다.
System.out.println("현재 채널은 " + t.channel + " 입니다.");

순서

1. 클래스 작성
2. 객체의 생성
3. 객체의 사용
   3단계로 사용할 것

• Tv 인스턴스 중 하나인 t를 print해보면 주소가 찍히는 이유
• 대입 연산자로 공간에 객체 주소를 대입해주는 것

생각 해보기

Java 언어를 접하면서 왜? 객체지향에 특화되어있는 지, 고민과 함께 공부를 하고 있음 일단, 기본적으로 객체지향 개념 (규칙)을 어느 정도 암기가 필요하다는 사실도 알게 됨 Python도 그렇고 JAVA도 class를 print했을 때 주소값이 나오는게 이해가 되지않았는데 강의를 듣고 메모리 측면과 함께 생각하니 당연하다고 생각이 들었음 ( 접근을 통해 이해가 되서 많이 놀램 ) 추후, 남궁성님 유튜브 강의를 공부하고 체화 시킨 후 지속적인 업로드를 할 예정

Reference

남궁성님 유튜브 강의를 보고 작성하였습니다. https://www.youtube.com/watch?v=p1ZZnM715ao&list=PLW2UjW795-f5JPTsYHGAawAck9cQRw5TD&index=4&ab_channel=남궁성의정석코딩

• 왜 쓰는지에 대해 이해하는 것이 중요하다.
• BFS, DFS 용어에서 유추가 되듯이 먼저, 탐색(Search)에 대해 생각해 볼 필요가 있다.

1.1 탐색(Search)

• 알고리즘을 시작하면서 쉽게 접하게 되는 주제이다.
• 단순히 이름 그대로 원하는 데이터를 검색하는데 최적으로 도달하기 위한 기법이라고 하기에는 다양한 문제(분야)에 접목이 된다. ( 위키피디아 - 검색 알고리즘 )
• 여러 탐색 알고리즘 ( 현재 정확히 알고 있는 알고리즘 기준)
  • 완전탐색
  • 이진탐색 (Binary search)
  • 깊이우선탐색 ( Depth-First Search )
  • 너비우선탐색 ( Breadth-First Search)
  • 해시탐색 (아직 잘 모르는 개념 - 시간이 가장 빠른 것만 알고 있음)

Search Algorithm 특징

여기까지 보았을 때 탐색 알고리즘에는 각 특징들이 있고 왜? 쓰는지에 대해 대략적으로 해소는 되지만 실제 코딩 문제에 봉착했을 때 DFS를 쓸 지 BFS에 대해서는 판단 기준은 서지 않는다. 일단은 DFS와 BFS에 대해 자세히 알아보자!

2. depth-first search (DFS)

2.1 DFS란?

• 먼저, input으로 들어가게 되는 인접행렬, 인접 리스트와 같은 개념은 생략하였다.
• 백문이 불여일견이다.

• 왼쪽부터 계층을 모두 거쳐 오른쪽으로 탐색을 진행한다.
• 위의 그림을 보았을 때 깊이 우선 탐색이라는 말이 와닿는다.
• 다시 말하면, 갈 수 있는 만큼 계속해서 탐색하다가 갈 수 없게 되면 다른 방향으로 다시 탐색하는 구조입니다.
• 실행 과정
  1. 노드를 방문하고 깊이 우선으로 인접한 노드를 방문한다. ( 1 → 2 )
  2. 또 그 노드를 방문해서 깊이 우선으로 인접한 노드를 방문한다. ( 2 → 3 → 4 )
  3. 만약 끝에 도달했다면 리턴한다. ( 4 → X )

반복하다가 → 갈 수가 없게 되면 → 탈출 조건 즉, 재귀함수를 이용해서 구현할 수 있음 재귀함수는 stack 특성을 가짐 즉, stack을 이용해 DFS를 구현한다는 것을 의미

재귀함수는 F(n+1) = ? X F(n) 구조를 찾는 것이 중요! (TIL-1 재귀함수 참고) DFS(node) = node + DFS(node와 인접하지만 방문하지 않은 다른 node)로 생각해 볼 수 있음

2.2 DFS 구현

• 예시 1) 인접 리스트가 주어질 때, 모든 노드를 DFS 순서대로 방문하시오.

2.2.1 인접 리스트 (Adjacent list)

graph = {
    1: [2, 5, 9],
    2: [1, 3],
    3: [2, 4],
    4: [3],
    5: [1, 6, 8],
    6: [5, 7],
    7: [6],
    8: [5],
    9: [1, 10],
    10: [9]
}

graph = [[],
         [2, 5, 9],
         [1, 3],
         [2, 4],
         [3],
         [1, 6, 8],
         [5, 7],
         [6],
         [5],
         [1, 10],
         [9]]

• 인접리스트를 딕셔너리로 표현하느냐, 리스트로 표현하느냐에 따른 표현의 차이 ( 접근하는 슬라이싱만 제대로하면 문제될게 없음)
• 짧지만 코딩 문제 경험상 이중 리스트 구조로 표현하는 것이 괜찮을 것으로 보인다. ( [ [] *len()])과 같은 표현으로 쉽게 구성 가능 )
• graph[i] 에서 i의 의미는 "i에서"라는 시작의 의미이므로 graph[0]은 빈 리스트를 가진다.
• 위의 그림의 예제를 이용한 것이다. 따라서 DFS에 의해 방문 순서를 구하게 되면 [1,2,3,4,5,6,7,8,9,10]이 정답이 된다.

2.2.2 구현을 위한 생각

• 구현 방법

  1. 루트 노드부터 시작한다.
  2. 현재 방문한 노드를 visted =[] 에 추가한다.
  3. 현재 방문한 노드와 인접한 노드 중 방문하지 않은 노드에 방문한다.
  4. 2, 3을 반복하며 계층 끝에 도달한다.

• *왜 stack을 이용하는지에 대한 생각 * stack은 FILO인 선입후출 개념 따라서 처음 시작 노드와 인접한 노드를 모두 저장해두고 가장 왼쪽의 노드의 모든 계층을 탐색한 이후 되돌아와 저장해 둔 노드 중 방문하지 않은 다음 노드로 넘어감 → 이런 논리는 stack으로 구현하면 알맞음

• 예시를 통한 이해 1과 인접한 (2, 5, 9) 저장 → 2와 인접한 3 → 3과 인접한 4 → 다시 돌아와 1과 인접한 5를 탐색 이후 반복

2.2.3 구현

• 구현 방법에 따른 코드

visited = []

# dictionary의 경우
def dfs_recursion(adjacent_graph, cur_node, visited_array):
    visited_array.append(cur_node)
    for adjacent_node in adjacent_graph:
        if adjacent_node not in visited_array:
            dfs_recursion(adjacent_graph, adjacent_node, visited_array)
    return

# list의 경우
def dfs_recursion(adjacent_graph, cur_node, visited_array):
    visited_array.append(cur_node) # (1)
    for adjacent_node in adjacent_graph[cur_node]: # (2)
        if adjacent_node not in visited_array: # (2)
            dfs_recursion(adjacent_graph,adjacent_node,visited_array) # (3)
    return visited_array # (4)

dfs_recursion(graph, 1, visited)
print(visited)

(result) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

• (1) : 현재 노드를 visted에 추가
• (2) : 인접 리스트를 통해 추가된 노드와 인접한 노드를 찾은 후, visited에 없는지 확인
• (3) : (1)과(2)는 반복적인 작업이므로 재귀함수를 통해 cur_node만 바꿔줌
• (4) visted_array는 방문 순서를 나타냄

위의 예제는 DFS의 가장 뼈대가 되는 것으로 이해가 중요!

3. Breadth-first search (BFS)

3.1 BFS란?

• 백문이 불여일견

• 같은 계층을 모두 탐색한 이후 다음 계층을 탐색하는 과정을 거침
• 1에 인접한 [2, 3, 4] 노드를 모두 queue에 저장한 이후 가장 처음에 넣은 노드를 꺼내서 탐색을 시작함
• "가장 처음에 넣은 노드"가 의미하는 것이 큐를 이용하여 BFS를 구현할 수 있음

3.2 BFS 구현

3.2.1 인접 리스트

graph = [[],
         [2, 3, 4],
         [1,5],
         [1,6, 7],
         [1,8],
         [2,9],
         [3,10],
         [3],
         [4],
         [5],
         [6]]

• 이중 리스트로 결과가 [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]이 나올 수 있도록 구성

3.2.2 구현 방법

1. 루트 노드를 큐에 넣습니다.
2. 현재 큐의 노드를 빼서 visited에 추가한다.
3. 현재 방문한 노드와 인접한 노드 중 방문하지 않은 노드를 큐에 추가한다.
4. 2와 3을 반복한다.
5. queue가 비면 탐색을 종료한다.

3.2.3 구현

• 구현 방법에 따른 코드

from collections import deque

def bfs_queue(adj_graph, start_node):
    queue = deque([start_node]) # (1)
    visited = [] # (1)
    while queue: # (2)
        current_node = queue.popleft() #(3)
        visited.append(current_node) #(3)
        for adj_node in adj_graph[current_node]:
            if adj_node not in visited:# (4)
                queue.append(adj_node) 
    return visited

• 리스트로 구현할 수 있지만 실제 프로젝트에서 queue를 구현한다고 했을 때 내장된 자료구조인 deque를 이용하는 것이 좋음
• (1) : 시작 노드를 queue에 넣어주고 방문 정보 역할을 하는 visited라는 빈 리스트를 생성한다.
• (2) : queue에 원소가 없을 때 까지 while을 돌린다.
• (3) : queue.popleft() 를 이용해 첫번째 인덱스의 원소를 꺼낸 후 visited에 추가한다.
• (4) : current_node와 인접해 있는 노드 중 visited에 있지 않은 노드를 queue에 추가한다.

확실히, 재귀함수를 이용하는 DFS보다 이해하기는 쉬움!