스프링 Restful API 서비스 구축 [KITRI 교육 Day2]

복습

 

REST(Representational State Transfer)

REST 의 정의

• 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미
• 즉, 자원의 표현에 의한 상태 전달
  • 자원의 표현
    • 자원 : 해당 소프트웨어가 관리하는 모든 것
    • 자원의 표현 : 그 자원을 표현하기 위한 이름
    • -> Ex) DB의 학생 정보가 자원일 때, 'students'를 자원의 표현으로 정함
  • 상태(정보) 전달
    • 데이터가 요청되어지는 시점에 자원의 상태(정보)를 전달
    • JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적
• 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일
• 네트워크 상에서 Client 와 Server 사이의 통신 방식 중 하나

REST 의 개념

• HTTP URI 를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT DELETE) 를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미
  • 즉 REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미
  • 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
  • CRUD Operation
    • Create: 생성(POST)
    • Read: 조회(GET)
    • Update: 수정(PUT)
    • Delete: 삭제(DELETE)
    • HEAD: header 정보 조회(HEAD)

REST 의 장단점

• 장점
  • HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구축할 필요가 없다.
  • HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해준다.
  • HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
  • REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
  • 서버와 클라이언트 역할을 명확하게 분리
• 단점
  • 표준이 존재하지 않음
  • 사용할 수 있는 메소드가 4가지(HTTP Method) 뿐
  • 구형 브라우저에서 아직 제대로 지원해주지 못하는 부분이 존재
    • PUT, DELETE를 사용하지 못하는 점

REST API

REST API 란

• API
  • 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용을 촉진하며, 서로 정보를 교환가능 하도록 하는 것
• REST API의 정의
  • REST 기반으로 서비스 API를 구현한 것
  • OpenAPI(누구나 사용할 수 있는 공개된 API) 는 대부분 REST API를 제공

REST API의 설계 기본 규칙

• URI는 자원의 정보를 표시해야 한다.
  • resource는 동사보다는 명사를, 대문자보다는 소문자를 사용한다
  • resource의 도큐먼트 이름으로는 단수 명사를 사용해야 한다
  • resource의 컬렉션 이름으로는 복수 명사를 사용해야 한다
  • resource의 스토어 이름으로는 복수 명사를 사용해야 한다 
  • GET /Member/1 -> GET /members/1

• 자원에 대한 행위는 HTTP Method(GET, PUT, POST, DELETE) 로 표현한다.
  • URI에 HTTML Method가 들어가면 안된다
  • GET /members/delete/1 -> DELETE /members/1
  • URI에 행위에 대한 동사 표현이 들어가면 안된다(CRUD 기능을 나타내는 것은 URI에 사용하지 않는다.)
  • GET /members/show/1 -> GET /members/1 GET /members/insert/2 -> POST /members/2
  • 경로 부분 중 변하는 부분은 유일한 값으로 대체한다(즉 :id는 하나의 특정 resource를 나타내는 고유값이다)
    • Ex) student를 생성하는 route: POST/students
    • Ex) id=12인 student를 삭제하는 route: DELETE/students/12

REST API 설계 규칙

1. 슬래시 구분자(/)는 계층 관계를 나타내는데 사용한다. 
2. http://restapi.example.com/houses/apartments
3. URI 마지막 문자로 슬래시를 포함하지 않는다
   • URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르며 URI도 달라져야 한다.

     http://restapi.example.com/houses/apartments/ (x)

4. 하이픈(-) 은 URI 가독성을 높이는데 사용
   • 불가피하게 긴 URI 경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.
5. 밑줄(_)은 사용하지 않는다.
   • 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용 x
6. URI 경로에는 소문자가 적합
   • URI 경로에 대문자 사용은 피하도록 한다
   • RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문
7. 파일 확장자는 URI에 포함하지 않는다.

REST API 설계 예시

RESTful의 개념

RESTful이란

• RESTful은 일반적으로 REST라는 아키텍쳐를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
  • REST API를 제공하는 웹 서비스를 RESTful하다고 할 수 있다.
• RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것이 아니다.
  • 즉, REST 원리를 잘 따르는 시스템은 RESTful 용어로 지칭된다.

RESTful의 목적

• 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것

RESTful하지 못한 경우

• CRUD 기능을 모두 POST 로만 처리하는 API
• route에 resource, id 외의 정보가 들어가는 경우

출처 - https://velog.io/@seokkitdo/Network-REST%EB%9E%80-REST-API%EB%9E%80-RESTful%EC%9D%B4%EB%9E%80

---

2일차

- Data-Transfer-Object 패턴 - JSON 포맷 다루기 - HTTP 메소드와 CRUD 매핑 - Restful API 테스팅

-

- API 응답 포맷 - CRUD 작업과 HTTP 메소드 - CRUD 오퍼레이션 실습

7

14

YAML

YAML은 XML, C, 파이썬, 펄, RFC2822에서 정의된 e-mail 양식에서 개념을 얻어 만들어진 '사람이 쉽게 읽을 수 있는' 데이터 직렬화 양식이다. "YAML은 마크업 언어가 아니다.

 

여러 군데에서 XML기반의 마크업 언어에서 YAML으로 변경        // 인프라 분야에서도 YAML파일로 거의 대체되고있음 

 

 

---

JPA는 기술 명세이다

JPA는 Java Persistence API의 약자로, 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스이다. 여기서 중요하게 여겨야 할 부분은, JPA는 말 그대로 인터페이스라는 점이다. JPA는 특정 기능을 하는 라이브러리가 아니다. 마치 일반적인 백엔드 API가 클라이언트가 어떻게 서버를 사용해야 하는지를 정의한 것처럼, JPA 역시 자바 어플리케이션에서 관계형 데이터베이스를 어떻게 사용해야 하는지를 정의하는 한 방법일 뿐이다.

 

Hibernate는 JPA의 구현체이다

Hibernate는 JPA라는 명세의 구현체이다. 즉, 위에서 언급한 javax.persistence.EntityManager와 같은 인터페이스를 직접 구현한 라이브러리이다. JPA와 Hibernate는 마치 자바의 interface와 해당 interface를 구현한 class와 같은 관계이다.

“Hibernate는 JPA의 구현체이다”로부터 도출되는 중요한 결론 중 하나는 JPA를 사용하기 위해서 반드시 Hibernate를 사용할 필요가 없다는 것이다. Hibernate의 작동 방식이 마음에 들지 않는다면 언제든지 DataNucleus, EclipseLink 등 다른 JPA 구현체를 사용해도 되고, 심지어 본인이 직접 JPA를 구현해서 사용할 수도 있다. 다만 그렇게 하지 않는 이유는 단지 Hibernate가 굉장히 성숙한 라이브러리이기 때문일 뿐이다.

 

Spring Data JPA는 JPA를 쓰기 편하게 만들어놓은 모듈이다

필자는 Spring으로 개발하면서 단 한 번도 EntityManager를 직접 다뤄본 적이 없다. DB에 접근할 필요가 있는 대부분의 상황에서는 Repository를 정의하여 사용했다. 아마 다른 분들도 다 비슷할 것이라 생각한다. 이 Repository가 바로 Spring Data JPA의 핵심이다.

Spring Data JPA는 Spring에서 제공하는 모듈 중 하나로, 개발자가 JPA를 더 쉽고 편하게 사용할 수 있도록 도와준다. 이는 JPA를 한 단계 추상화시킨 Repository라는 인터페이스를 제공함으로써 이루어진다. 사용자가 Repository 인터페이스에 정해진 규칙대로 메소드를 입력하면, Spring이 알아서 해당 메소드 이름에 적합한 쿼리를 날리는 구현체를 만들어서 Bean으로 등록해준다.

Spring Data JPA가 JPA를 추상화했다는 말은, Spring Data JPA의 Repository의 구현에서 JPA를 사용하고 있다는 것이다. 예를 들어, Repository 인터페이스의 기본 구현체인 SimpleJpaRepository의 코드를 보면 아래와 같이 내부적으로 EntityManager을 사용하고 있는 것을 볼 수 있다.

 

요약 - 셋을 혼동하지 말고 사용하자

아래 사진은 위의 내용을 요약하여 JPA, Hibernate, 그리고 Spring Data JPA의 전반적인 개념을 그림으로 표현한 것이다.

특히 JPA와 Spring Data JPA는 똑같이 JPA가 들어가서 처음 접하는 사람은 상당히 헷갈릴 수 있다. 이 세 개념의 차이점을 정확히 인지하고 숙지하고 있으면 개발이 한층 편해질 것이다.

 

참조 - JBoss Hibernate docs

 

// JAVA GUIDE  자바 관련 참고하면 좋은 사이트

https://www.javaguides.net/

---

//별첨