📚 Java 웹 기술은 서블릿과 JSP로 시작해 MVC 패턴을 거쳐 MVC 프레임워크의 도입으로 구조화되었으며, 이후 어노테이션 기반의 Spring MVC와 비동기 처리에 최적화된 Spring WebFlux로 발전해왔다.

 

  1. Servlet의 등장 (1997)
    • 개요
      • Java를 사용한 웹 개발의 시초로, 서버에서 동적으로 콘텐츠를 생성하기 위해 사용되었다. 클라이언트의 요청을 받고, 그에 대한 응답을 생성하는 기본적인 구조를 제공했다.
    • 단점
      • 코드의 복잡성이 증가하고 유지보수가 어려워졌다.
  2. JSP (JavaServer Pages) 도입 (1999)
    • 개요
      • JSP는 HTML 내에 Java 코드를 삽입할 수 있는 기술로, 웹 페이지를 더 쉽게 동적으로 생성할 수 있도록 도와주었다.
    • 단점
      • JSP 내에 비즈니스 로직을 분리할 수 없다.
  3. Servlet, JSP 기반의 MVC 패턴 도입
    • 개요
      • MVC 패턴이 도입되면서, UI, 비지니스 로직, 데이터를 분리하여 개발하는 방식이 등장했다.
      • Servlet은 주로 컨트롤러(비지니스 로직)로 사용되었고, JSP는 뷰(UI)를 담당하게 되었다.
    • 장점
      • MVC 패턴은 웹 애플리케이션의 유지보수성과 확장성을 크게 향상시켰다.
    • 단점
      • 개발자가 중복적으로 설정해줘야 하는 부분들이 다수 발생했다.
  4. MVC 프레임워크의 등장과 발전 (2000~2010)
    • 개요
      • Struts, Spring 등의 MVC 프레임워크가 등장하며, 웹 애플리케이션 개발이 더욱 구조화되고 효율적으로 변했다.
      • 그중 Spring MVC는 단순하면서도 강력한 기능을 제공하여, Java 웹 개발의 표준으로 자리 잡게 되었다.
      • 중복적으로 설정해야 하는 부분들을 프레임워크로 자동화 했다.
    • 단점
      • 여전히 애플리케이션 개발 관련 설정이 복잡했다.
  5. Annotation 기반의 Spring MVC(2007~현재)
    • 개요
      • Annotation을 통해 애플리케이션 설정의 복잡함을 줄여주었다.
    • 장점
      • 더 직관적이고 간결한 방식으로 웹 애플리케이션을 개발할 수 있게 되었다.
  6. Spring Boot의 등장(2014~현재)
    • 개요
      • Spring 프레임워크를 보다 쉽게 사용하도록 만든 도구로, 설정과 복잡한 초기 설정 작업을 자동화했다.
      • 내장 Tomcat을 가지고 있다.
    • 장점
      • 개발자들이 빠르게 애플리케이션을 개발할 수 있도록 도와준다.
  • 최신 기술 동향
    1. Web Servlet
      • Spring MVC
        • 안정적이고 동기식 프로그래밍 모델을 기반으로 한 웹 애플리케이션 개발에 널리 사용된다.
    2. Web Reactive
      • Spring WebFlux
        • 비동기 및 넌블로킹 모델을 기반으로 한 웹 프레임워크로, 높은 동시성을 요구하는 애플리케이션에서 효율적인 성능을 제공한다. 함수형 프로그래밍 스타일을 지원하며, 서블릿 기술 대신 Netty 등의 비동기 서버를 사용한다.
        • 서블릿 기술을 사용하지 않으며, 실시간 데이터를 처리하거나 높은 동시성을 요구하는 애플리케이션에 적합하다.
        • RDBMS 지원 부족과 높은 기술적 난이도 등으로 인해, 아직은 MVC 모델이 많은 실무에서 더 많이 사용되고 있다.

'Back-End (Web) > JAVA' 카테고리의 다른 글

[JAVA] 열거형 ( Enum )  (0) 2024.11.22
[JAVA] HASH란 무엇인가  (1) 2024.11.21
[JAVA] 자바의 정렬  (0) 2024.11.21
[JAVA] 응용 정리  (1) 2024.11.15
[JAVA] NULL  (0) 2024.11.13
요구사항 API URI 설계
  회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제
  회원 목록 조회 /read-member-list
• 회원 조회 /read-member-by-id
• 회원 등록 /create-member
• 회원 수정 /update-member
• 회원 삭제 /delete-member

 

단적으로 위의 설계는 틀린 방식이다.

가장 중요한 것은 리소스 식별

 

API URI 고민

URI(Uniform Resource Identier)

 

• 리소스의 의미는 뭘까?

  • 회원을 등록하고 수정하고 조회하는게 리소스가 아니다!
  • 예) 미네랄을 캐라 -> 미네랄이 리소스
  • 회원이라는 개념 자체가 바로 리소스다.

• 리소스를 어떻게 식별하는게 좋을까?

  • 회원을 등록하고 수정하고 조회하는 것을 모두 배제
  • 회원이라는 리소스만 식별하면 된다. -> 회원 리소스를 URI에 매핑
요구사항 API URI 설계
  회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제
  회원 목록 조회 /members
• 회원 조회 /members/{id}
• 회원 등록 /members/{id}
• 회원 수정 /members/{id}
• 회원 삭제 /members/{id} 

참고: 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장(member -> members)

 

 

리소스와 행위 분리

가장 중요한 것은 리소스를 식별하는 것

 

• URI는 리소스만 식별!

• 리소스와 해당 리소스를 대상으로 하는 행위을 분리

  • 리소스: 회원
  • 행위: 조회, 등록, 삭제, 변경

• 리소스는 명사, 행위는 동사 (미네랄을 캐라)

• 행위(메서드)는 어떻게 구분?

'CS ( Computer Science ) > 네트워크 (Networking)' 카테고리의 다른 글

[Net] Cookie  (1) 2024.12.28
[Net] MVC 패턴  (0) 2024.12.13
[Net] Rendering  (1) 2024.12.05
[Net] Servlet  (1) 2024.12.04
[Net] Web Application  (1) 2024.12.03

+ Recent posts