스프링 3주차 과제 제출할 때 문제

• API 뜻 참고
  • 클라이언트가 정한대로 서버에게 요청(Request)을 보내면, 서버가 요구사항을 처리하여 응답(Response)을 반환합니다.
  • 클라이언트 - 서버 간의 약속입니다.

★수정, 삭제 API의 request를 어떤 방식으로 사용하셨나요? (param, query, body)

문제 분석 참고

참고 굿굿 https://medium.com/@bouncewind0105/request-param-query-body-%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90-2e7e4fddd8b9

 

---

1. Request param,query, body 의 차이점

-- Request 객체는 API를 컨트롤하기 위한 메소드를 셋 담고 있다.

그것이 각각

• param
• query
• body

이다

각각의 설명하자면

1. req.param

주소에 포함된 변수를 담는다. 예를 들어 https://okky.com/post/12345 라는 주소가 있다면 12345를 담는다

2. req.query

주소 바깥, ? 이후의 변수를 담는다. 예를 들어 https://okky.com/post?q=Node.js 일 경우 Node.js를 담는다

3. req.body

XML, JSON, Multi Form 등의 데이터를 담는다. 당연히 주소에선 확인할 수 없다.

사실상 3번은 햇갈릴 일이 없다. 1번과 2번을 주의하면 되겠다.

 

---

2. 스프링 controller에서 파라미터를 받는 다양한 방법 ( @RequestParam, @RequestBody, @PathVariable)

https://velog.io/@shson/%EC%8A%A4%ED%94%84%EB%A7%81-controller%EC%97%90%EC%84%9C-%ED%8C%8C%EB%9D%BC%EB%AF%B8%ED%84%B0%EB%A5%BC-%EB%B0%9B%EB%8A%94-%EB%8B%A4%EC%96%91%ED%95%9C-%EB%B0%A9%EB%B2%95-RequestParam-RequestBody-PathVariable

 

내 대답 : param

• 나는 요청하는 주소에 둘 다 "/api/blogs/{id}"를 써서 param 방식을 썼다.(어노테이션은 @PathVariable으로 메서드에 매개변수를 받았다.)

<내 코드>

//삭제 메서드
@DeleteMapping("/api/blogs/{id}")
public Long deleteBlog(@PathVariable Long id){
    blogRepository.deleteById(id);
    return id;
}

//업데이트 메서드
@PutMapping("/api/blogs/{id}")
public Long updateBlog(@PathVariable Long id, @RequestBody BlogRequestDto requestDto) {
    blogService.update(id, requestDto);
    return id;
}

 

 

★어떤 상황에 어떤 방식의 request를 써야하나요?

문제분석 참고

1. @RequestParam, @PathVariable, @RequestBody

https://u0hun.tistory.com/21

 

내 대답

param(@PathVariable)은 Rest api에서 값을 호출할 때 주로 많이 사용한다. URI 경로의 일부를 파라미터로 사용할 때 이용한다. 템플릿 변수의 값을 추출하고 그 값을 메소드 변수에 할당한다.

query(@RequestParam)는 파라미터의 값과 이름을 함께 전달하는 방식으로 게시판 등에서 페이지 및 검색 정보를 함께 전달하는 방식을 사용할 때 많이 사용한다.

body(@RequestBody)는 xml이나 json 기반의 메시지를 사용하는 요청의 경우 유용하다.

 

★RESTful한 API를 설계했나요? 어떤 부분이 그런가요? 어떤 부분이 그렇지 않나요?

문제분석 참고

--- 강의 참고

• REST
  • 여기에 쓰이는 동사는 우리가 JPA 시간에 배운 CRUD를 지칭합니다.
  • 즉 A에 대해 생성(POST)/조회(GET)/수정(PUT)/삭제(DELETE) 요청을 하는 것이죠.
  • 예시
    • GET /courses → 강의 전체 목록 조회 요청
    • GET /courses/1 → ID가 1번인 녀석 조회 요청
    • POST /courses → 강의 생성 요청
    • PUT /courses/3 → ID가 3번인 녀석 수정 요청
    • DELETE /courses/2 → ID 2번인 녀석 삭제 요청
  • 주의사항
    • 주소에 들어가는 명사들은 복수형을 사용합니다.
      • /course
    • 주소에 동사는 가급적 사용하지 않습니다.
      • /accounts/edit
• 👉 REST란, 주소에 명사, 요청 방식에 동사를 사용함으로써 의도를 명확히 드러냄을 의미합니다.

---

RESTful API

RESTful 이란

• HTTP와 URI 기반으로 자원에 접근할 수 있도록 제공하는 애플리케이션 개발 인터페이스이다. 기본적으로 개발자는 HTTP 메소드와 URI 만으로 인터넷에 자료를 CRUD 할 수 있다.
• 'REST API'를 제공하는 웹 서비스를 'RESTful' 하다고 할 수 있다.
• RESTful은 REST를 REST 답게 쓰기 위한 방법으로, 누군가가 공식적으로 발표한 것은 아니다.

RESTful API 개발 원칙

a. 자원을 식별할 수 있어야 한다.

• URL (Uniform Resource Locator) 만으로 내가 어떤 자원을 제어하려고 하는지 알 수 있어야 한다. 자원을 제어하기 위해서, 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미이다.
• Server가 제공하는 정보는 JSON 이나 XML 형태로 HTTP body에 포함되어 전송 시킨다.

b. 행위는 명시적이어야 한다.

• REST는 아키텍쳐 혹은 방법론과 비슷하다. 따라서 이런 방식을 사용해야 한다고 강제적이지 않다. 기존의 웹 서비스 처럼, GET을 이용해서 UPDATE와 DELETE를 해도 된다.
• 다만 REST 아키텍쳐에는 부합하지 않으므로 REST를 따른다고 할 수는 없다.

c. 자기 서술적이어야 한다.

• 데이터에 대한 메타정보만 가지고도 어떤 종류의 데이터인지, 데이터를 위해서 어떤 어플리케이션을 실행 해야 하는지를 알 수 있어야 한다.
• 즉, 데이터 처리를 위한 정보를 얻기 위해서, 데이터 원본을 읽어야 한다면 자기 서술적이지 못하다

d. HATEOS (Hypermedia as the Engine of Application State)

• 클라이언트 요청에 대해 응답을 할 때, 추가적인 정보를 제공하는 링크를 포함할 수 있어야 한다.
• REST는 독립적으로 컴포넌트들을 손쉽게 연결하기 위한 목적으로도 사용된다. 따라서 서로 다른 컴포넌트들을 유연하게 연결하기 위해선, 느슨한 연결을 만들어줄 것이 필요하다.
• 이때 사용되는 것이 바로 링크이다. 서버는 클라이언트 응용 애플리케이션에 하이퍼 링크를 제공한다.
• 클라이언트는 이 하이퍼 링크를 통해서 전체 네트워크와 연결되며 HATEOAS는 서버가 독립적으로 진화할 수 있도록 서버와 서버, 서버와 클라이언트를 분리 할 수 있게 한다.

---

RESTFul 하다는 의미?

API 의 엔드포인트가 단 하나이고,

요청과 응답에 대한 메타데이터는 HTTP 프로토콜을 사용해서 전달해야하며,

요청 메서드는 POST ( CREATE ) , GET ( READ ), PUT ( UPDATE) , DELETE ( DELETE) 를 사용하고,

요청 URL에는 동사를 사용하지 않아야 한다.

 

---

RESPT API란

REST의 원리를 따르는 API를 의미한다.

하지만 REST API를 올바르게 설계하기 위해서는 지켜야 하는 몇가지 규칙이 있다.

--------------------------------

RESTFUL이란

REST의 원리를 따르는 시스템을 의미합니다.

하지만 REST를 사용했다 하여 모두가 RESTful 한 것은 아니다.  REST API의 설계 규칙을 올바르게 지킨 시스템을 RESTful하다 말할 수 있으며 모든 CRUD 기능을 POST로 처리 하는 API 혹은 URI 규칙을 올바르게 지키지 않은 API는 REST API의 설계 규칙을 올바르게 지키지 못한 시스템은 REST API를 사용하였지만 RESTful 하지 못한 시스템이라고 할 수 있습니다.

 

내 대답

강의를 따라하면서 하다보니 CRUD(생성, 조회, 변경, 삭제) 를 생성(POST)/조회(GET)/수정(PUT)/삭제(DELETE) 행위로 요청하고 자원(요청하는 주소)들을 REST API의 규약을 지키면서 만들게 되었습니다. 요청하는 주소에 동사는 쓰지 않고 명사를 썼습니다. 그리고 명사들을 복수형으로 썼습니다. 경로에는 대문자보다는 소문자를 썼고 주소에 마지막에 슬래시를 쓰지 않았습니다. REST 규칙을 준수하면서 API를 만들었습니다.
그런데 password 조회하는 부분은 강의를 따라하지 않고 혼자 생각하면서 만들다 보니깐 명사를 쓰기는 했지만 복수형으로 쓰지 못했습니다.

 

 

 

 

참고자료

https://velog.io/@somday/RESTful-API-%EC%9D%B4%EB%9E%80

RESTful API 이란

https://khj93.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-REST-API%EB%9E%80-REST-RESTful%EC%9D%B4%EB%9E%80

[네트워크] REST API란? REST, RESTful이란?

https://devkingdom.tistory.com/108

[Spring] Spring MVC 로 RESTFul 서비스 개발하기 (1)