스프링 Restful API 서비스 구축 (한국정보기술연구원 교육)

스프링 Restful API 서비스 구축

[내외부 연계모듈 구현하기]                   클릭하면 해당 위치로 이동
- Spring Framework (Sectful Web Service 소개)
- REST 서비스의 이해
- 스프링 프레임워크와 REST

 

 

서버사이드 렌더링 (Server Side Rendering)

• 클라이언트(브라우저)가 서버에 매번 데이터를 요청하여 서버에서 처리하는 방식 
• 클라이언트에서 요청이 들어올 때마다 매번 서버에서 새로운 화면(View)을 만들어 제공
  (서버가 화면을 그리는 주체인 셈) 

 

• 논리적으로 구분되어있는 구조
• 레이어별로 영향을 별로 미치지 않는다. (바로 아래에만 영향 有)
• 서비스발행에 대한 (인터페이스) 표준을 만들어줘야 한다.

 

 

MVC Pattern    클래스 수가 많아지지만 역할 구분으로 설계, 개발시 편리하다는 장점
Model	- 어플리케이션 상태의 캡슐화 - 상태 쿼리에 대한 응답 - 어플리케이션의 기능 표현 - 변경을 VIEW에 통지
View	- 모델을 화면에 시각적으로 표현 - 모델에게 업데이트 요청 - 사용자의 입력을 컨트롤러에 전달 - 컨트롤러가 View를 선택하도록 허용
Controller	- 요청 입력값 체크 - 사용자 액션을 모델 업데이트와 mapping - 일정 범위에 모델 데이터 저장 - 응답에 대한 view 선택

 

Spring Framework

• 엔터프라이즈 급 애플리케이션을 만들기 위한 모든 기능을 종합적으로 제공하는 경량화 된 솔루션
• JavaEE(Java Enterprise Edition)가 제공하는 다수의 기능을 지원하고 있기 때문에 JEE를 대체하는 Framework
• Spring Framework는 JavaEE가 제공하는 다양한 기능을 제공하는 것 뿐만 아니라,
  DI(Dependency Injection)나 AOP(Aspect Oriented Programming)와 같은 기능 지원

 

Spring Framework 특징

• POJO (Plain Old Java Object)
• PSA (Portable Service Abstraction)
• IoC/DI (Inversion Of Control/Dependency Injection)
• AOP (Aspect Oriented Programming)

Spring AOP (개념, 용어, 원리, 포인트컷 표현식, JoinPoint API)

 

Spring Boot

Spring Boot

특징

• project에 따라 자주 사용되는 library들이 미리 조합
• 복잡한 설정을 자동으로 처리
• 내장 서버를 포함해서 tomcat과 같은 WAS를 추가로 설치하지 않아도 개발 가능
• WAS에 배포하지 않고도 실행할 수 있는 JAR파일로 Web Application을 개발

 

Spring DI Container

• BeanFactory : Spring DI Container가 관리하는 객체를 빈(Bean)이라 하고, 이 빈들의 생명주기를 관리
• ApplicationContext : Bean Factory에 여러 가지 컨테이너 기능 추가

 

Code > Container 방향 (스프링 쪽으로 알려주는 방법은 두가지)

선언적 방법(해당되는 XML이나 YML, Properties / Annotation)과 Programatic한 방법(Java Code 활용)

 

스프링 컨테이너가 작성해준 걸 갖다 쓸 때는 APZ 활용

 

 

 

---

REST 서비스의 이해

REST (Representational State Transfer)

• 2000년도 로이 필딩의 박사 학위 논문에 최초로 소개
• REST는 'Representational State Transfer'의 약어로 하나의 URI는 하나의 고유한 리소스를 대표하도록 설계된다는 개념에 전통 방식을 결합해 원하는 작업을 지정
   URI  +  GET / POST / PUT / DELETE 
• 웹의 장점을 최대한 활용할 수 있는 아키텍처(설계 구조)로써 REST를 발표
• HTTP URI를 통해 제어할 자원(Resource)를 명시하고 HTTP Method(GET, POST, PUT, DELETE)을 통해 해당 자원(Resource)를 제어하는 명령을 내리는 방식의 아키텍처
• REST API 설계는 실용주의 관점으로 유지하는 아키텍처 스타일  (표준은 아님)
  • 자원(Resource) - URI
  • 행위(Verb) - method (GET / POST / PUT / DELETE)
  • 표현(Representations) - DATA (XML, CSU, JSON ...)

 

• 동사 대신 명사 사용
  • /getUserList -> /users
  • /getBoardList -> /boards
• 상태 변경 시 GET 메서드와 쿼리 파라미터 사용 금지
  • GET /api/users?action=delete&userId=123 -> DELETE /api/users/123
  • Create : POST
  • Read : GET
  • Update : PUT
  • Delete : DELETE
• 복수 명사 사용
  • GET /user -> GET /users
• 관계 형태 표현에 하위 리소스 사용
  • GET /depts/IT/users/홍길동 : IT부서의 홍길동 검색
• 에러 정보 제공
  • HTTP 상태 코드를 사용
  • 실제 상태코드는 세 가지 정도만 제공하면 되고 필요시 더 추가
  • 더 추가할 경우, 최대 8개를 넘지 않도록 할 것
  • 상태코드를 사용하더라도 사용자에게 가능한 자세한 메시지 제공