Restful API 설계의 과정은 다양한 경우의수를 전부 따져가며 설계를 해야할 필요가 있다. 또한 서버는 클라이언트에게 통신의 성공 부터 실패까지 전부 통틀어서 결과를 내뱉을 수 있어야 함.
REST API 에 대해 이론적으론 알고 있고, 여러 문서를 참고하며 어떤식으로 설계해야 하는지 대충 안다고 생각했는데, 지난 프로젝트 리펙토링 과정에서 꽤 지켜지지 않은 api 들이 있다는 것을 깨달았다. 따라서 다음 프로젝트때 api 네이밍에 있어서 주의하면 좋을 것들을 정리해 보고자 한다.
간단한 문서 반환
/api/task/{id}?select=task.id,task.user.id
"As soon as you want to filter on the data returned by yourserver, you will be forced to use syntax that will differentiate the fields or your entities.
put 과 patch 구분
post - 새로운 데이터를 쓸때 사용
put - 전체 컬럼을 수정할 때 사용
patch - 일부 컬럼만 수정할 때 사용
Response Code 지키기
Json Response 형식 지키기
## [옳은 예시] 북마크 생성 시 Response
{
"message": "북마크가 생성되었습니다.",
"bookMark": {
"HitProducId": 1532,
"hitProductTitle": "오리진 엑세스 베이직 내일까지 1018원입니다."
}
}
## [옳은 예시 2] 북마크 생성 시 Response : 더 세세하게 해보자면..?
{
"message": "북마크가 생성되었습니다.",
"bookMark": {
"HitProduct" {
"id": 1532,
"title": "오리진 엑세스 베이직 내일까지 1018원입니다."
}
}
}
## [나쁜 예시] 북마크 생성 시 Response
{
"message": "북마크가 생성되었습니다.",
"bookmarkHitProducId": 1532,
"bookmarkHitProductTitle": "오리진 엑세스 베이직 내일까지 1018원입니다."
}
?? 동사를 그냥 처 박자
https://www.youtube.com/watch?v=JMH3cfW-8r8
https://dev.to/khalyomede/design-an-easy-to-use-and-flexible-rest-endpoints-3fia
https://yoonho-devlog.tistory.com/95
https://meetup.toast.com/posts/92
https://yuda.dev/250