[Project] API, REST, REST API

이해를 목적으로 한 포스팅 2..... ! 출처는 아래 링크이다.

https://velog.io/@wkahd01/%ED%8C%80-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-1%EC%A3%BC%EC%B0%A8.-%EC%9A%A9%EC%96%B4-%EC%A0%95%EB%A6%AC-2

팀 프로젝트 1주차. (용어 정리 2)

 

1. API

API는 애플리케이션 소프트웨어를 구축하고 통합하기 위한 정의 및 프로토콜 세트로, 애플리케이션 프로그래밍 인터페이스(Application Programming Interface)를 나타낸다.

이러한 API를 통해 컴퓨터 프로그램 간 상호작용을 촉진하며, 서로 정보를 교환 가능하도록 한다.

 

쉽게 정리하자면, API는 당사자들 간 계약을 나타내는 도큐멘테이션을 갖춘 계약으로 비유할 수 있다. 

한 쪽 당사자가 특정한 방식으로 구성된 원격 요청을 보내면 다른 쪽 당사자의 소프트웨어가 이에 응답하는 방식으로 구성되어 있기 때문이다. 

API가 뭔지 몰랐는데 대박... 무슨 말인지 더 모르겠어서 더 찾아봤다.

---

일단, UI는 뭘까?

먼저 API의 약자 중 Interface가 뭔지부터 알아야한다. GUI나 UI(/UX..)라는 말은 들어본 적이 있다.

UI(사용자 인터페이스, User Interface)는 사용자와 기계나 시스템 같은 사물이 소통하는데 도움을 주는 매개체이다.

 

가장 많이 예시로 드는 것은 스마트폰의 홈 버튼이나 전원 버튼이다. 홈 버튼을 누르면 바탕화면으로 한 번에 이동이 가능하다. 만약 홈 버튼 없이 바탕화면으로 가려면 어떻게 해야할까? 뭐 바로 못 간다.  "바탕화면으로 이동!!"이라는 요청을 기기에 전달해주는게 홈 버튼이다. 이 경우 홈 버튼이 UI이다. 홈 버튼도 기기의 일부이지만 스마트폰과 사용자를 이어주는 매개체인 것이다.

 다른 예시로는 보통 우리는 바탕화면과 시작메뉴에 있는 아이콘들을 더블 클릭하며 응용 프로그램들을 실행한다. CLI 환경에서 접속하고 있진 않다. CLI는 Command Line Interface의 약자로, 말그래도 명령줄이 보이는 화면이라고 할 수 있다. 응용 프로그램들이 GUI(그래픽 사용자 인터페이스, Graphic User Interface)의 일부이다. GUI가 없었다면 아주 불편하지만 CLI를 썼을 것이다. CLI( Command Line Interface)도 역시 인터페이스이기 때문에 파일 시스템에 접근하거나 프로그래밍을 등을 할 수 있다. 

여기서 볼 수 있는 UI와 GUI 그리고 CLI의 공통점은 어떤 사물(스마트폰, 컴퓨터, 인터넷 등)과 사용자 사이를 이어주는 다리 역할을 한다는 점이다. API도 마찬가지이다.

 

API 개념과 장점

흔히 API를 레스토랑에 빗대어 표현하기도 한다. 손님(내가 만드는 프로그램)이 웨이터(API)에게 주문을 한다. 그럼 웨이터는 내 주문 내역을 주방(API 제공자, like 기상청, 공공포탈 등)에 갖다준다. 주방에서 요리를 해 웨이터에게 주면 웨이터가 다시 손님에서 음식을 가져다준다. 웨이터(API)가 손님의 주문을 주방으로 전달하는 매개체 역할을 하는 것이다. 

여기서 손님은 주방에서 무슨 일이 일어나는지 잘 모른다. 대개는 관심이 없으며 관심을 가질 필요도 없다. 이것이 API의 장점이다.!! 내가 가져다쓰려는 API의 기능을 어떻게 구현하는지 몰라도 되고 난 그저 AIP가 갖다주는 걸 사용만 하면 된다. 시간과 노력을 동시에 아낄 수 있다. 이처럼 API는 처음부터 개발하거나 유지 보수할 필요가 없는 외부 데이터와 기능에 접속할 수 있게 해준다.

 

API는 문서 공개 없으면 쓸 수 없다.

API는 프로그램과 프로그램 간 다리, 프로그램을 위한 인터페이스이다. 자세하게 설명하자면 데이터를 주고 받기 위한 방법과 그 규격을 뜻한다. 여기서 데이터는 환율 정보, 미세먼지 정보, 날씨 정보와 같은 것들이다. 

API는 public, protected, private API 등으로 나뉘어 있는데 public은 우리가 다 알고 쓰는 공공 포탈 API이다. 공공 포탈이 아니더라도 개발자 등록을 하고 키를 받아서 얼마간 무료로 쓸 수 있는건 거의 다 public이라고 보면 된다. 이에 반해 private은 API 제공자가 API를 공개하지 않은 것이다. 쉽게 말하면 사용법을 알려주지 않아서 쓸 수가 없어서 개발자가 그 제공자의 API를 쓸 수 없다. API 문서가 바로 이 사용법과 규격을 제공하는 문서이다. 이 사용법이 제공되어 있지 않다면 private이다. 보통 API 제공자들을 DB, 기능을 모듈화해서 인증받은 사용자(개발자키가 있는 사람들)에게 규격화된 명령으로 데이터를 가져갈 수 있게 한다.

이 API는 공짜 음식일 때도 있고 일정량 이상을 먹으면 돈을 내야하는 음식일 때도 있다. 

 

API의 예시

API는 UI와 달리 사용자 눈에 보이지 않는다. 그런 면에서 앞의 레스토랑 예시가 완벽한 건 아니다.
다른 예시로는 열쇠를 API의 예시로 들 수 있다. 거대한 인터넷 세상의 사원인 우리는 어느 자료실에 가서 자료를 가져와야 할 때마다 관리자들에게 열쇠를 요청한다. 관리자들에게 이름을 알리고 복사키를 받아가면 자료를 갖다 쓸 수 있는 것이다. 하지만 구글의 검색 순위 알고리즘이나 페이스북 사용자 데이터베이스를 조회하는 열쇠 이런건 요청할 수 없다. 그건 제작자들이 허락하지 않은 private API이기 때문이다. 

=> 대박..... 완벽하게 이해됐다.

 

실용성 있는 예시를 들어보겠다. 내가 어떤 웹페이지를 만들었다. 정말 이 세상에 다시 없는 미친 디자인이고 콘텐츠도 획기적이다! 최대한 많은 사람들이 와서 이 페이지를 구경해주면 좋겠다고 생각한다. 그래서 페이지에 공유 버튼을 만들기로 했다. 사람들이 네이버를 많이 쓰니까 네이버에 공유하기를 하고 싶다. 어떻게 해야 할까?

 

제일 단순하게는 블로그나 카페, 밴드 등에 그냥 링크를 복사해서 게시물로 올리면 된다. 하지만 버튼 하나로 공유할 수 있는 방법은 없을까? 네이버에서는 그 방법을 제공한다.

 

네이버 공유하기 개발가이드

여길 보면 utf-8 인코딩을 해서 url과 title 값을 넣어 GET 방식으로 요청을 해야 한다. 인코딩을 하지 않은 건 잘못된 예시라고 알려준다. 이런 게 API 규격이다. "공유하고 싶으면 이렇게 쓰세요!" 알려주는 것이다. 만약 이런 게 없다면 웹페이지에 서비스 공유하는 버튼을 만들 수가 없을 것이다. 만약에 할 수 있다고 해도 공식이 알려주는 방법이 없으니 돌아돌아 먼 길을 가야 할 수도 있다.

내 페이지가 네이버 API를 사용해서 사용자들이 네이버 서비스에 내 페이지를 공유할 수 있도록 요청하는 것이다.

 

[참고] (https://dev-dain.tistory.com/50)

 

요약

• 개발자가 프로그램을 만드는데 필요한 어떤 기능을 직접 구현하지 않고 API 제공자들이 제공하는 데이터와 모듈 등을 갖다 쓸 수 있게 해주는게 API와 API 문서이다.
• 예를 들어 내가 네이버를 통해 내 페이지를 네이버 서비스에 공유하고 싶다면 네이버에서 제공하는 공유하기 API를 문서에서 제시하는대로 맞춰서 쓰면 된다.
• API가 공개되지 않았다면 쓸 수 없다. 또 공개 API라고 하더라도 호출 횟수가 많아지면 비용을 지불해야 할 수도 있다.

---

2. REST

Representational State Transfer의 약자로, 

엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 

여기서 '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다.

 

간단한 의미로는, 웹 상의 자료를 HTTP 위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.

REST는 HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)를 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용할 수 있다.

 

REST 구성 요소

1. 자원(Resource): URL

• 모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
• 자원을 구별하는 ID는  ‘/groups/:group_id’와 같은 HTTP URI 다.
• Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.

2. 행위(Verb): HTTP Method

• HTTP 프로토콜의 Method를 사용한다.
• HTTP 프로토콜은 GET, POST, PUT, DELETE와 같은 메서드를 제공한다.

3. 표현(Representation of Method)

• Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
• REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
• JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

요약

• 자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
• 즉, 자원(resource)의 표현(representation)에 의한 상태 전달

---

3. REST API

REST 기반으로 서비스 API를 구현하는 것

• 사내 시스템들도 REST 기반으로 시스템을 분산해 확장성과 재사용성을 높여 유지보수 및 운용을 편리하게 할 수 있다.
• REST는 HTTP 표준을 기반으로 구현하므로, HTTP를 지원하는 프로그램 언어로 클라이언트, 서버를 구현할 수 있다.
• REST API를 제작하면 델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등을 이용해 클라이언트를 제작할 수 있다.

일단 대충 이해는 완료...! 하지만 더 설명이 필요하다.

 

[SPRING] REST API 구현 방법 - 로그인

Spring을 사용하는 곳에선 Restful API 개발 경험이 자격요건에 들어간다고 한다.

로그인 구현을 Restful하게 하는 것 도대체 어떤 것인가!!

 

* REST API 이란?

URI(Resource)로 정보의 자원을 표현하고 HTTP Method(GET, POST, PUT, DELETE)로 자원에 대한 행위를 조합하여 API를 설계한다. 주요 측면으로 Respresentation(자원의 표현)은 JSON, XML, HTML 등의 다른 형식으로 표현된다.

 

* Spring MVC 컨트롤러와 REST 컨트롤러의 차이점

HTTP 응답 바디가 생성되는 방식 (

MVC 컨트롤러는 View 기술을 사용하는 반면 REST 컨트롤러는 객체를 반환하면 객체 데이터가 JSON/XML 형식의 HTTP 응답에 직접 작성된다!

Spring MVC

- Dispatcher Servlet: Client의 요청을 처리하는 역할을 한다. 공통 처리 작업을 Dispatcher Servlet이 처리한 후, 적절한 세부 Controller로 작업을 위임한다. Dispatcher Servlet이 처리하는 url 패턴을 지정해줘야 한다. ex) /*.do

- Handler Mapping: 웹 요청이 들어올 경우 Dispatcher Servlet 객체가 요청을 어떤 Controller에게 위임할지 결정해야 하는데 그 요청들을 처리하는 Controller의 맵핑을 담당하는 인터페이스

 

Spring MVC-RestController

Spring 4.0부터 @Controller와 @ResponseBody를 합친 것 이상의 역할을 하는 @RestController를 추가했다.

@RestController는 리턴값에 자동으로 @ResponseBody를 붙게되어 HTTP 응답데이터(body)에 자바 객체가 매핑되어 전달된다. 그러므로 @ResponseBody를 추가할 필요없다.

 

* URI 표현

ex) GET/members/{id}

=> id로 회원을 조회하는 API라면 @PathVariable("id")를 파라미터 앞에 붙여줘서 값을 얻어올 수 있다.

 

[@RestController]

- 로그인 정보 조회

@Autowired
BCryptPasswordEncoder passwordEncoder;    //비밀번호 암호화

@PostMapping("/user/login")
public MemberVO login (@RequestBody LoginVO loginVo) {    //HTTP요청의 내용을 객체에 매핑하기 위해 @RequestBody 를 설정.
   // @Controller인 경우 @ResponseBody를 적어야한다.
    MemberVO memberVo = new MemberVO();

    String userId = loginVo.getUserId();
    String inPw = loginVo.getPassWord();

    int userCount = loginService.getUserCount(userId);    //UserID로 user가 존재하는지 확인.
    if (userCount == 1) {
        String pw = loginService.getUserPassword(userId);    //UserID로 DB에 저장된 인코딩된 비밀번호를 가져옴.
        if (passwordEncoder.matches(inPw, pw)) {    //디코딩해서 확인
            System.out.println("비밀번호가 일치합니다.");
            loginVo.setUserPassword(pw);
            memberVo = loginService.login(loginVo);
        } else {
            System.out.println("비밀번호가 불일치합니다.");
        }
    }
    return memberVo;
}
 
Colored by Color Scripter
cs

* 로그인은 정보 조회와 다름 없지만 GET을 사용하는 경우 ID, PASSWORD 정보 노출이 있기 때문에 POST를 사용하여 정보의 보안을 생각해야한다.

 

* 비밀번호 보안

 비밀번호 보안으로 Spring Security 또는 DB 암호화를 사용한다. DB 암호화는 보안상 취약하므로 Spring Security를 사용하여 구현한다.

스프링 시큐리티에서 제공하는 PasswordEncoder 구현 클래스로 2가지가 있다. 

 

[참고] (https://goodncuteman.tistory.com/3)