22년 08월 26일 작성글
Rest API
훌륭한 DB 디자인으로 시작하라.
클라이언트 사이드 프로그램이 데이터 호출에 어려움을 느낀다면 DB구조가 별로라고 생각해봐라.
엔티티간에 반복적인 연결관계를 만들지마라.
테이블에는 관련있는 데이터만 넣자.
새로운 테이블을 추가할 때는 완전 바꾸지말고 기존 테이블에서 추가할 수 있어야 한다.
결과적으로 DB 정규화를 잘 해야한다.
User부분 URL
GET /api/users : 사용자들을 모두 반환
GET /api/users/{id} : 사용자들 중 id인 사용자 반환
GET /api/users/{id}/task : 사용자들 중 id인 사용자의 task 반환
POST /api/users : 새로운 유저 만들기 (200 or 201을 반환받으면 생성된 것)
PUT /api/users/{id} : id인 사용자 업데이트(Rest 규약에는 PUT을 보낼 때는 user에 해당하는 모든 정보를 보내주라고 명시되어 있음. 일부만 변경할 때는 FETCH. 하지만 PUT도 일부만 업데이트 하도록 만드는 경우도 있다.)
REST 규약에는 URL에 동사를 넣지말라고 하고 있다. 가장 중요하다.
Task 부분 URL
GET /api/task : task들 모두 반환
그 유저가 가지고 있지 않은 부분을 보여줘야 하는 것도 이상하고... 이렇게 애매한 부분들이 있다는 것을 알 필요 있다.
GET /api/task/{id} : id에 해당하는 task 반환
GET /api/task/{id}/users : task과 연관된 유저들 반환
...
DELETE /api/task/{id} : id에 해당하는 task 삭제
DELETE /api/task/{id}/user/{id} : id에 해당하는 user 삭제
이 부분은 조금 이상한 것 같다. user를 삭제하는지 모르겠다.
GET /api/task/{id}?select=task.id,task.user.id :
task.id와 task.user.id만 반환해달라.(좋은 방법이다.)
Rest는 stateless
유저가 무슨 권한을 가지고 있는지 모든 내용을 API를 요청할 때마다 요청정보에 두고 있다. 그렇기 때문에 서버는 state에 저장할 필요가 없다.
세션 방식 로그인이 아닌 JWT 방식의 로그인을 사용하여 각 요청마다 사용자 검사
내용출처
