RESTful 이란?
- REpresentationl State Transfer
- 클라이언트와 서버 간의 결합성을 줄이는 가이드 (fe,be 따로 작업 가능할 수 있도록)
- 클라이언트가 사용할 api를 보기 좋게 만들 수 있는 가이드
API를 RESTful하게 설계하는 방법
1) Client Server Architecture
- 서버와 클라이언트의 분리
2) Statelessness
- 서버 사용하는 대상이 있음
- 요청 받을 때마다 해당 사용자가 누군지 매번 체크해야 함
- 즉 사용자의 상태 저장하지 않음
- 리퀘스트 보내는 클라이언트는
자신을 증명할 책임이 존재 (보안과 관련) - 원하는 기능을 위한 상태는 client가 가져야 한다 (내가 글을 수정할 지, 삭제할 지 등)
3) Cacheability
- 한번 정보 받으면 이 정보가
캐싱 가능한지 여부체크 해야 한다 - 상태를 저장할 수 없으니깐 캐시로 정보를 저장하기
4) Layered System
- 서버와 클라이언트 간에 계층적인 구조 존재
- 하지만 클라이언트는 서버에 도달하기까지의 과정을 알 필요 없음
5) Uniformed interface
- 일관된 인터페이스
=> 자원을 나타내기 위해서 사용해야 하는 인터페이스
=> 돌려줄 땐 json을 돌려준다 등
6) Code on Demand (옵션적인 기능)
- 일시적 기능의 확장
- 사용 가능한 코드를 응답을 보내서 사용자 기능을 일시적으로 확장하기
고려해야 할 사항
1) uri
- uri를 통해 전달될 데이터는 아래의 형식으로
-> 1) 경로를 통해 도달하고자 하는 자원을 지정
-> 2) 방법을 통해 자원에 실행할 기능 지정
RequestMapping 재구성
package dev.dongyun.crud.post;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.*;
import java.util.ArrayList;
import java.util.List;
@RestController
@RequestMapping("post")
public class PostRestController {
private static final Logger logger = LoggerFactory.getLogger(PostRestController.class);
private final List<PostDto> postList;
public PostRestController(){
this.postList = new ArrayList<>();
}
@PostMapping()
public void createPost(@RequestBody PostDto postDto){
logger.info(postDto.toString());
this.postList.add(postDto);
}
@GetMapping()
public List<PostDto> readPostAll(){
logger.info("read-all");
return this.postList;
}
//GET
//GET /post?id=0
@GetMapping("{id}}")
public PostDto readPost(@PathVariable("id") int id){
logger.info("in read post");
return this.postList.get(id);
}
@PutMapping("{id}")
public void updatePost(
@PathVariable("id") int id,
@RequestBody PostDto postDto
){
PostDto targetPost = this.postList.get(id); //업데이트를 위한 목적 타겟
if (postDto.getTitle()!=null){
targetPost.setTitle(postDto.getTitle());
}
if (postDto.getContent()!=null){
targetPost.setContent(postDto.getContent());
}
this.postList.set(id, targetPost);
}
@DeleteMapping("{id}")
public void deletePost(@PathVariable("{id}") int id){
this.postList.remove(id);
}
}
error - status code
https://ko.wikipedia.org/wiki/HTTP%EC%83%81%ED%83%9C%EC%BD%94%EB%93%9C
@ResponseStatus(HttpStatus.CREATED) 넣어주기!
2xx (성공)
이 클래스의 상태 코드는 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
200(성공): 서버가 요청을 제대로 처리했다는 뜻이다. 이는 주로 서버가 요청한 페이지를 제공했다는 의미로 쓰인다.
201(작성됨): 성공적으로 요청되었으며 서버가 새 리소스를 작성했다.
202(허용됨): 서버가 요청을 접수했지만 아직 처리하지 않았다.
203(신뢰할 수 없는 정보): 서버가 요청을 성공적으로 처리했지만 다른 소스에서 수신된 정보를 제공하고 있다.
204(콘텐츠 없음): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 제공하지 않는다.
205(콘텐츠 재설정): 서버가 요청을 성공적으로 처리했지만 콘텐츠를 표시하지 않는다. 204 응답과 달리 이 응답은 요청자가 문서 보기를 재설정할 것을 요구한다(예: 새 입력을 위한 양식 비우기).
206(일부 콘텐츠): 서버가 GET 요청의 일부만 성공적으로 처리했다.
207(다중 상태, RFC 4918)
208(이미 보고됨, RFC 5842)
226 IM Used (RFC 3229)
4xx (요청 오류)
4xx 클래스의 상태 코드는 클라이언트에 오류가 있음을 나타낸다.
400(잘못된 요청): 서버가 요청의 구문을 인식하지 못했다.
401(권한 없음): 이 요청은 인증이 필요하다. 서버는 로그인이 필요한 페이지에 대해 이 요청을 제공할 수 있다. 상태 코드 이름이 권한 없음(Unauthorized)으로 되어 있지만 실제 뜻은 인증 안됨(Unauthenticated)에 더 가깝다.[2]
402(결제 필요): 이 요청은 결제가 필요합니다.
403(Forbidden, 금지됨): 서버가 요청을 거부하고 있다. 예를 들자면, 사용자가 리소스에 대한 필요 권한을 갖고 있지 않다. (401은 인증 실패, 403은 인가 실패라고 볼 수 있음)
404(Not Found, 찾을 수 없음): 서버가 요청한 페이지(Resource)를 찾을 수 없다. 예를 들어 서버에 존재하지 않는 페이지에 대한 요청이 있을 경우 서버는 이 코드를 제공한다.
405(허용되지 않는 메소드): 요청에 지정된 방법을 사용할 수 없다. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우, 또는 읽기 전용 리소스에 PUT 요청을 보내는 경우에 이 코드를 제공한다.
406(허용되지 않음): 요청한 페이지가 요청한 콘텐츠 특성으로 응답할 수 없다.
407(프록시 인증 필요): 이 상태 코드는 401(권한 없음)과 비슷하지만 요청자가 프록시를 사용하여 인증해야 한다. 서버가 이 응답을 표시하면 요청자가 사용할 프록시를 가리키는 것이기도 한다.
408(요청 시간초과): 서버의 요청 대기가 시간을 초과하였다.
5xx (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다
500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없다.
501(구현되지 않음): 서버에 요청을 수행할 수 있는 기능이 없다. 예를 들어 서버가 요청 메소드를 인식하지 못할 때 이 코드를 표시한다.
502 (Bad Gateway, 불량 게이트웨이): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 잘못된 응답을 받았다.
503(서비스를 사용할 수 없음): 서버가 오버로드되었거나 유지관리를 위해 다운되었기 때문에 현재 서버를 사용할 수 없다. 이는 대개 일시적인 상태이다.
504(게이트웨이 시간초과): 서버가 게이트웨이나 프록시 역할을 하고 있거나 또는 업스트림 서버에서 제때 요청을 받지 못했다.
505(HTTP 버전이 지원되지 않음): 서버가 요청에 사용된 HTTP 프로토콜 버전을 지원하지 않는다.
