엔드포인트 관련해서 여쭈어봅니다. 정보
엔드포인트 관련해서 여쭈어봅니다.본문
그누보드 DB에서 g5_content는 관리자모드에서 설정한 글이고..
g5_write_게시판에서 작성한 게 게시물인데
어떻게 보면 content가 게시물로 볼 수도 있을텐데
그냥 DB 맞춰서
/content는 g5_content
/post 는 g5_write_... 에 맞추는 게 나을까요..?? (/write 는 아무리 생각해도 아닌 것 같아 /post로 했습니다)
아니면 그냥 제 맘대로 커스텀하는 게 나을까요.
그누보드 사용자 입맛에 맞춰서 만들려고 하는데
그렇게 생각하자니 전자같기도 하고...
추천
0
0
댓글 3개
웹서버에서 POST, GET, PUT, DELETE 같이 method를 활성화 할수 없다면,
(보통 그누보드 호스팅 받는 서버들은 POST, GET이 전부임)
url path 마지막을 action 처리로 쓰는게 적절하다고 봅니다.(정규식으로 추출)
action 으로 따지면 post 나 write나 어느걸 써도 상관없죠. (modify, put, update..)
url path의 마지막이 post|update|delete 셋중에 하나가 아니라면 get으로 처리
이런 처리가 router의 핵심 기능일 될것이고, router 에서 추출한걸 적당한 클래스 또는 service 로 전달하는 것이 dispatcher 가 될것이고, 디스패처는 다시 각각의 controller 를 call하는 형태가 되겠죠.
구도는 어떤식으로 잡느냐에 따라서 형태가 달라지겠지만,
@GolangKR 님이 고민하는것처럼 초기 설계를 어떤 형태로 할것인가가 가장 고민이 많이 되는 부분입니다.
아무쪼록 좋은 결과 있으시길 바랍니다.
(보통 그누보드 호스팅 받는 서버들은 POST, GET이 전부임)
url path 마지막을 action 처리로 쓰는게 적절하다고 봅니다.(정규식으로 추출)
action 으로 따지면 post 나 write나 어느걸 써도 상관없죠. (modify, put, update..)
url path의 마지막이 post|update|delete 셋중에 하나가 아니라면 get으로 처리
이런 처리가 router의 핵심 기능일 될것이고, router 에서 추출한걸 적당한 클래스 또는 service 로 전달하는 것이 dispatcher 가 될것이고, 디스패처는 다시 각각의 controller 를 call하는 형태가 되겠죠.
구도는 어떤식으로 잡느냐에 따라서 형태가 달라지겠지만,
@GolangKR 님이 고민하는것처럼 초기 설계를 어떤 형태로 할것인가가 가장 고민이 많이 되는 부분입니다.
아무쪼록 좋은 결과 있으시길 바랍니다.
RESTful API는 GET POST PUT DELETE 규격의 HTTP Method를 받아 처리해야합니다.
REST API는 사용하는 사람의 대부분이 예상가능하고 동의할수있는 수준의 설계원칙을 가져야하며 단순하게 json 포맷의 데이터만 반환하는걸 REST API라고 부르지는 않죠.
@솔그루 님이 얘기하신 것처럼 그누보드가 동작하는 대부분의 국내 웹호스팅의 대부분이 GET POST 외에는 차단되어있기 때문에 문제가 있지만 헤더나 요청에 폴백을 두어(_method=delete 요청 값 추가 또는 헤더) 처리하는게 일반적입니다.
하지만 API서버가 PHP 웹서버는 아닐테니 상관없겠죠.
https://learn.microsoft.com/ko-kr/azure/architecture/best-practices/api-design
리소스 이름은 적절하게 변경하는게 낫다고 생각합니다. 그누보드의 DB 테이블이나 필드명 모두 난해한 것들이 많고 필드명에 쓰잘데없는 접두사들이 붙어있습니다.
API를 사용하는 사람은 그누보드에 익숙한 웹개발자일수도 있지만 앱이나 기타 다른 소프트웨어의 개발자일수 있습니다. API 설계는 DB 구조에 맞추는게 아니라 리소스 접근에 필요한 예상 가능하고 불필요한 추측을 배제하는 명확한 구조를 갖춘 설계를 가지는게 맞다고 봅니다.
응답 데이터 또한 DB 필드를 그대로 반환해야하는 것도 아닙니다. 필요에 따라 적절히 가공이 필요합니다. 게시물의 글쓴이 데이터에 mb_id, wr_name을 그대로 반환하는게 아니라 author: {no: 1, memberId: 'admin', name: '관리자', isMember: true} 처럼 적절히 가공되는 편이 낫고요. 게시물이 비밀글인지 공지글인지 확인하기위해 DB 필드명과 값이 무엇인지를 파악하기위해 DB를 열어보거나 어떤 값들이 들어가는지 확인할 필요 없도록 isSecret: true/false를 반환하거나 readable, accessible 같은 속성을 반환하는게 낫겠죠.
게시판 정보 또한 클라이언트 측에 로그인된 사용자 권한으로 글을 쓸수 있는지 미리 알려줄수있어야 장문의 글을 쓰고 저장 버튼을 누르고 나서야 ‘레벨이 낮아서 이 게시판에 글을 쓸수 없습니다’ 같은 메시지를 받지 않겠죠.
DB 구조를 그대로 반환하거나 이름만 적당히 바꿔서만 되는건 아니죠.
API 매뉴얼에 write는 대체 무엇인가 설명을 읽지 않아도 목차에 나열된 리소스 이름만 보고도 필요한 것을 찾아낼수 있어야겠죠. 리소스 목록에 post, article 같은 예상 가능한 이름대신 write가 있다면 그걸 눌러서 상세 설명을 보기전까진 게시물을 가져오는 리소스 경로가 무엇인지는 찾기 어려울 겁니다.
REST API는 사용하는 사람의 대부분이 예상가능하고 동의할수있는 수준의 설계원칙을 가져야하며 단순하게 json 포맷의 데이터만 반환하는걸 REST API라고 부르지는 않죠.
@솔그루 님이 얘기하신 것처럼 그누보드가 동작하는 대부분의 국내 웹호스팅의 대부분이 GET POST 외에는 차단되어있기 때문에 문제가 있지만 헤더나 요청에 폴백을 두어(_method=delete 요청 값 추가 또는 헤더) 처리하는게 일반적입니다.
하지만 API서버가 PHP 웹서버는 아닐테니 상관없겠죠.
https://learn.microsoft.com/ko-kr/azure/architecture/best-practices/api-design
리소스 이름은 적절하게 변경하는게 낫다고 생각합니다. 그누보드의 DB 테이블이나 필드명 모두 난해한 것들이 많고 필드명에 쓰잘데없는 접두사들이 붙어있습니다.
API를 사용하는 사람은 그누보드에 익숙한 웹개발자일수도 있지만 앱이나 기타 다른 소프트웨어의 개발자일수 있습니다. API 설계는 DB 구조에 맞추는게 아니라 리소스 접근에 필요한 예상 가능하고 불필요한 추측을 배제하는 명확한 구조를 갖춘 설계를 가지는게 맞다고 봅니다.
응답 데이터 또한 DB 필드를 그대로 반환해야하는 것도 아닙니다. 필요에 따라 적절히 가공이 필요합니다. 게시물의 글쓴이 데이터에 mb_id, wr_name을 그대로 반환하는게 아니라 author: {no: 1, memberId: 'admin', name: '관리자', isMember: true} 처럼 적절히 가공되는 편이 낫고요. 게시물이 비밀글인지 공지글인지 확인하기위해 DB 필드명과 값이 무엇인지를 파악하기위해 DB를 열어보거나 어떤 값들이 들어가는지 확인할 필요 없도록 isSecret: true/false를 반환하거나 readable, accessible 같은 속성을 반환하는게 낫겠죠.
게시판 정보 또한 클라이언트 측에 로그인된 사용자 권한으로 글을 쓸수 있는지 미리 알려줄수있어야 장문의 글을 쓰고 저장 버튼을 누르고 나서야 ‘레벨이 낮아서 이 게시판에 글을 쓸수 없습니다’ 같은 메시지를 받지 않겠죠.
DB 구조를 그대로 반환하거나 이름만 적당히 바꿔서만 되는건 아니죠.
API 매뉴얼에 write는 대체 무엇인가 설명을 읽지 않아도 목차에 나열된 리소스 이름만 보고도 필요한 것을 찾아낼수 있어야겠죠. 리소스 목록에 post, article 같은 예상 가능한 이름대신 write가 있다면 그걸 눌러서 상세 설명을 보기전까진 게시물을 가져오는 리소스 경로가 무엇인지는 찾기 어려울 겁니다.
먼저 문서화가 필요합니다. Swagger와 같은 문서로 API에 대한(그누보드로 시작해서 한국형 realworld형으로)..
REST를 처음 만들다 보면, 그누보드 테이블에 Relationship이 없어서 놀라고, 각 필드이름에 불필요한 이름도 보여서 놀라고..
이름짖기 힘들기 때문에 초기에는 그누보드의 테이블 기준으로 일차로 만들고..
2차로 이름을 변경해 나가는 것이죠.. (1차를 건너도 좋고.)
https://sir.kr/so_restful/356 예전에 구현했던 기억으로는 중간에 필드이름변경하는 루틴도 있었던 기억이 있습니다.
Restful API에 관심이 있는 사람들이 모여서, 한국형 표준(?)을 하나 만들어 보는 것이 어떨까요?
@jihan6? @솔그루 @고랭지농업 @틀불 이렇게 관심이 있는 분들끼리 document화 (이름 짖기)부터 시작해 봄이 어떨지...
참고 모델 : https://codebase.show/projects/realworld?category=backend
REST를 처음 만들다 보면, 그누보드 테이블에 Relationship이 없어서 놀라고, 각 필드이름에 불필요한 이름도 보여서 놀라고..
이름짖기 힘들기 때문에 초기에는 그누보드의 테이블 기준으로 일차로 만들고..
2차로 이름을 변경해 나가는 것이죠.. (1차를 건너도 좋고.)
https://sir.kr/so_restful/356 예전에 구현했던 기억으로는 중간에 필드이름변경하는 루틴도 있었던 기억이 있습니다.
Restful API에 관심이 있는 사람들이 모여서, 한국형 표준(?)을 하나 만들어 보는 것이 어떨까요?
@jihan6? @솔그루 @고랭지농업 @틀불 이렇게 관심이 있는 분들끼리 document화 (이름 짖기)부터 시작해 봄이 어떨지...
참고 모델 : https://codebase.show/projects/realworld?category=backend
