도중에 root 계정의 비밀번호를 입력하라는 화면이 나타난다. 안전한 비밀번호를 입력하자.
dpkg -l | grep mysql-server
안전하게 설치가 되었는지 확인
ii mysql-server 5.7.17-0ubuntu0.16.04.1 all MySQL database server (metapackage depending on the latest version)
ii mysql-server-5.7 5.7.17-0ubuntu0.16.04.1 amd64 MySQL database server binaries and system database setup
ii mysql-server-core-5.7 5.7.17-0ubuntu0.16.04.1 amd64 MySQL database server binaries
위와 같은 메시지가 출력된다면 잘 설치된 것
2) 실행
sudo netstat -tap | grep mysql
MySQL 서버는 설치하면 자동으로 실행된다. MySQL 서버가 실행되고 있는지 확인
tcp 0 0 localhost:mysql *:* LISTEN 2556/mysqld
위 명령의 실행 결과로 아래와 같은 메시지가 출력되면 실행되고 있는 것
만약 MySQL 서버가 실행되지 않는다면 아래 명령을 입력
sudo systemctl restart mysql.service
3) 설정 파일 변경
cd /etc/mysql/mysql.conf.d
sudo vi mysqld.cnf
위 명령을 입력하면 mysqld.cnf 파일을 수정할 수 있다.
/bind-address
위 명령을 입력하여
bind-address = 127.0.0.1
bind-address = 0.0.0.0
127.0.0.1을 0.0.0.0으로 수정해준다. 아마 vi 명령어를 검색하면 수정할 수 있는 방법이 자세히 나와 있을 것이다.
esc 버튼을 여러번 누른 뒤 wq를 입력해주면 저장 후 종료가 된다.
설정 파일을 변경한 후에는 MySQL 서버를 재시작한다.
sudo systemctl restart mysql.service
2. MySQL Workbench 연결
1) MySQL Workbench 설치
2) 연결
Workbench를 실행한 후 [Database-Connect to Database]를 클릭
Connection Method를 Standard TCP/IP over SSH 로 변경
SSH Hostname에 본인 IP 입력 (IPv4 퍼블릭 IP)
SSH Username에 ubuntu
SSH Key File에 다운 받은 *.ppk 파일
password 에서 [Store in Vault] 버튼을 클릭하고 root 사용자의 비밀번호를 입력하면 된다.
Spring에서 컨트롤러를 지정해주기 위한 어노테이션은 @Controller와 @RestController가 있다.
전통적인 Spring MVC 컨트롤러인 @Controller와 Restful 웹 서비스의 컨트롤러 @RestController의 큰 차이점은 HTTP Response Body가 생성되는 방식이다.
1. @Controller (Spring MVC Controller)
[Controller - View]
전통적인 Spring MVC의 컨트롤러인 @Controller는 주로 View를 반환하기 위해 사용한다. 아래와 같은 과정을 통해 Spring MVC Container는 Client의 요청으로부터 View를 반환한다.
1. Client는 URI 형식으로 웹 서비스에 요청을 보낸다.
2. Mapping 되는 Handler와 그 Type을 찾는 DispatcherServlet이 요청을 인터셉트한다.
3. Controller가 요청을 처리한 후에 응답을 DispatcherServlet으로 반환하고, DispatcherServlet은 View를 사용자에게 반환한다.
[Controller - Data]
Spring MVC Controller 에서 Data를 반환해야 하는 경우가 있다. Spring MVC의 컨트롤러에서는 데이터를 반환하기 위해 @ResponseBody 어노테이션을 활용해야 한다. 이를 통해 Controller도 JSON 형태로 데이터를 반환할 수 있다.
1. Client는 URI 형식으로 웹 서비스에 요청을 보낸다.
2. Mapping 되는 Handler와 그 Type을 찾는 DispatcherServlet이 요청을 인터셉트한다.
3. @ResponseBody를 사용하여 Client에게 Json 형태로 데이터를 반환한다.
2. @RestController (Spring RESTful Controller)
Spring MVC 프레임워크에서 REST API를 구현할 때, 컨트롤러에 @RestController 어노테이션을 붙인다.
RestController의 액션 메소드가 리턴하는 Java 객체는 자동으로 JSON 포맷으로 변환되어 클라이언트에 전송된다.
RestController의 액션 메소드는 데이터를 클라이언트에 전송하기 때문에 뷰(view)가 필요 없다.
Spring MVC Controller에 @ResponseBody가 추가된 것이다. RestController의 주용도는 Json/xml 형태로 객체 데이터를 반환하는 것이다.
1. Client는 URI 형식으로 웹 서비스에 요청을 보낸다.
2. Mapping 되는 Handler와 그 Type을 찾는 DispatcherServlet이 요청을 인터셉트한다.
3. RestController는 해당 요청을 처리하고 데이터를 반환한다.
컨트롤러의 엑션 메소드 앞에 @ReponseBody 어노테이션을 붙이면, 이 액션 메서드가 리턴하는 Java 객체는 자동으로 JSON 포맷으로 변환되어 클라이언트에 전송된다.
@Controller
public class StudentController {
public @ResponseBody List<Student> students() {
List<Student> list = ...;
return list;
}
}
컨트롤러 앞에 @RestController 어노테이션을 붙였다면, 그 컨트롤러의 액션 메소드 앞에 @ResponseBody 어노테이션을 붙이지 않고 생략해도 된다.
@RestController
public class StudentController {
public List<Student> students() {
List<Student> list = ...;
return list;
}
}
RestController의 액션 메서드가 액션 메서드를 호출할 때 전송하는 request parameter 데이터도 JSON 포맷으로 전송하는 것이 일관적이라 좋다.
이렇게 JSon 포맷으로 전송된 request parameter 데이터를 받을 액션 메서드의 파라미터 변수에는 @RequestBody 어노테이션을 붙여주어야 한다.
public String update(@RequestBody Student student) { ... }
URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다. REST API는 분명한 URI를 만들어 통신을 해야하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
REST API 에서는 메시지 바디 내용의 포맥을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다. Accept header를 사용한다.
4-3. 리소스 간의 관계를 표현하는 방법
REST 리소스 간에 연관 관계가 있을 수 있는데 이런 경우 다음과 같은 표현 방법을 사용한다.
/리소스/리소스 ID/관계가 있는 다른 리소스명
예) GET: /users/{userid}/devices (일반적으로 소유 'has'의 관계를 표현할 때)
만약에 관계명이 복잡하다면('has'의 관계가 아닐 때) 이를 서브 리소스에 명시적으로 표현하는 방법이 있다. 예를 들면 사용자가 '좋아하는(like)' 디바이스 목록을 표현해야 할 경우
GET : /users/{userid}/likes/devices (관계명이 애매하거나 구체적 표현이 필요할 때)
4-4. 자원을 표현하는 Collection과 Document
Collection과 Document에 대해 알면 URI 설계가 한 층 더 쉬워진다. Document는 단순히 문서 또는 한 객체, Collection은 문서들의 집합, 객체들의 집합으로 생각한다. 컬렉션과 도큐먼트는 모두 리소스라고 표현할 수 있으며 URI에 표현된다.
http:// restapi.example.com/sports/soccer
위 URI에서 sports라는 컬렉션과 soccer이라는 도큐먼트로 표현되어 있다고 생각하면 된다.
sports, players 컬렉션과 soccer, 13(13번인 선수)를 의미하는 도큐먼트로 URI가 이루어지게 된다. 여기서 중요한 점은 컬렉션은 복수로 사용하고 있다는 점이다. 좀 더 직관적인 REST API를 위해서 컬렉션과 도큐먼트를 사용할 때 단수/복수를 지켜준다면 이해하기 쉬운 URI를 설계할 수 있다.
RESTful Web Service HTTP methods
Collection URI (예) http:// example.com/resourses
GET : 컬렉션에 속한 자원들의 URI나 그 상세사항의 목록을 보여준다.
PUT : 전체 컬렉션은 다른 컬렉션으로 교체한다.
POST : 해당 컬렉션에 속하는 새로운 자원을 생성한다. 자원의 URI는 시스템에 의해 할당된다.
DELETE : 전체 컬렉션을 삭제한다.
Element(Document) URI (예) http:// example.com/resoureces/item17
GET : 요청한 컬렉션 내 자원을 반환한다.
PUT : 해당 자원을 수정한다.
POST : 해당 자원에 귀속되는 새로운 자원을 생성한다.
DELETE : 해당 컬렉션 내 자원을 삭제한다.
5. HTTP 응답상태 코드
잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 한다. 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수가 있기 때문에 응답의 상태코드 값을 명확히 돌려주는 것은 생각보다 중요한 일이다.
상태코드
설명
200
클라이언트의 요청을 정상적으로 수행함.
201
클라이언트가 어떠한 리소스를 생성하길 요청. 해당 리소스가 성공적으로 생성됨 (POST를 통해 리소스 생성 작업 시)
400
클라이언트 요청이 부적절할 경우 사용하는 응답 코드
401
클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용하는 응답 코드
(로그인 하지 않은 유저가 로그인 했을 때, 요청가능한 리소스를 요청했을 때)
403
유저 인증상태와 관계없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드
(403보다는 400이나 404를 사용할 것을 구너고. 403 자체가 리소스가 존재한다는 뜻이기 때문에)
405
클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드
댓글 개