그누보드 API화에 대한 간단한 개발 이슈 정리 > RESTful

RESTful

그누보드 API화에 대한 간단한 개발 이슈 정리 정보

그누보드 API화에 대한 간단한 개발 이슈 정리

본문

1. 세션

 

비밀글에 대한 세션, 조회수 세션, 비밀글에 대한 세션

이건 그냥 그대로 활용해도 됩니다.

다만 api 권한을 정하는 로그인의 경우는 별도의 jwt나 auth 인증을 사용하는것이 낫다는 개인적인 생각입니다.

 

2.  외부에서 직접 페이지를 실행시키거나 하여 삭제나 회원가입 등을 강제로 요청하는 경우를 방지 위한 토큰 캡챠 처리

 

번거롭습니다. 토큰 부분이 commom.js, 각종 db 업데이트에 관여하는 업데이트 부분 등 다양하게 있습니다.

 

3. php 함수로 html을 출력하는 부분

 

예를들면 write_pages, editor_html get_sideview 등이 있습니다

api로 전달받으려면 이 부분도 배열화 시키거나 데이터 리턴값에 대한 규칙을 문서화 하여 만든 후 문서로 전달해줘야 합니다.

 

4. 권한 및 레벨 또는 게시판 설정에 따른 제한 값

 

글쓰기시 write데이터만 보내줄것이 아니라 이메일, 여분필드, 홈페이지 주소 등 설정된 데이터에 맞게 프론트앤드에서 표시할 수 있도록 구분값을 보내줘야합니다.

 

5. DB 업데이트 후 URL처리

 

그누보드의 경우 글 쓰기 후 해당 글 작성 url로 이동하거나 에러난 경우 다시 이전페이지로 돌아가는 부분이 있습니다

이 페이지 값과 동일한 리턴값을 보내주는 값을 전달을 해주거나, 이벤트 후 api주소를 리턴해주던가

아니면 문서화 해서 이 이벤트 후에는 호출해야하는 api를 알려줘야합니다.

 

6. 캐시, 훅

 

그누보드에서는 잦은 db쿼리를 막기 위해 자주 사용하지만 결과값이 자주 바뀌지 않는것들은 캐시화 하여 사용하고 있습니다

이것은 그대로 활용하여도 무방합니다.

훅도 마찬가지입니다 그대로 사용할 수 있으나, 일부 훅은 제거해줘야 하는 것들이 있습니다.

 

7. 패스워드 접근처리.

 

비회원 글, 댓글 삭제. 비밀글, 비밀댓글 접근 등 비밀번호를 입력해야하는 상황에서 그누보드는 별도의 password.php 페이지를 사용합니다

프론트앤드와 백앤드를 구분하는 api에선 이러한 구조의 형태를 띄기 상당히 번거로우며 비밀번호가 필요한 상황에서는 페이지 접근시 일정한 약속으로 만들어진 값을 리턴하고, 그 값을 프론트앤드에서 받은 경우 비밀번호 모달창이나 페이지를 이동하게 하여야하고, 
해당 페이지에서 비밀번호 처리하는 api에서 처리하여 결과물을 보여줘야합니다

단, 정상적인 페이지 접근 후에 해당 인증 과정이 거쳐져야 하므로 기존의 세션활용이나 별도의 토큰으로 관리해줘야 할 듯 합니다.

회원가입도 비슷한 이슈가 있습니다

 

6. 분리가 어설프게 되어있는 파일들

point.php, profile.php, scrap.php, search.php 등은 스킨 파일에만 html의 내용이 있는것이 아닌 원본 파일에도 html 파일들이 있습니다

이러한 부분에서도 어느정도 문서화하여 통일화 된 리턴값이나 규칙이 필요합니다.

 

7. 에디터 캡챠 등 필수적인 플러그인 문제

에디터의 경우 에디터마다 사용법이 다르기에 그누보드에선 editor.lib.php에서 필요한 html값을 리턴하고 있는데 api에서 이런식으로 제공하고 받는것은 별로 바람직한 방법이 아니라 생각되지만 딱히 html값, 필요한 script값을 api에서 제공해주고 프론트앤드에서 그대로 실행하는(vue-gnuboard 에서 적용된방법) 말고는 딱히 없어보이는데 괜찮은 아이디어 있으시면 알려주세요.

 

 

현재 그누보드 api화는 과거에 vue로  그냥 막무가내로 때려박았던 경험도 있고, php api도 어느정도 건드려본 경험이 있어서 생각보다는 빠른 진척,

하지만 언제 완성될지 모르는 작업량이 느껴지고 있습니다.

그래도  어느정도 모양새는 갖춘 형식으로 갖춰지긴 하고 있네요.

 

최대한 원본 사용자들도 접근할 수 있게 함수명이나 클래스명 등은 그누보드와 동치시키고 있지만

위에서 말한 이슈들은 별도로 문서화 해서 정리해야 할듯 합니다.

 

짬나는대로 만들어서 글작성, 글보기, 글목록, 프로필, 검색, 패스워드 접근처리(일부 미완성), latest, 인기검색어, 썸네일 생성 부분이 테스트까진 가능할 정도가 되었습니다

 

이번 주말에 아마도 테스트서버에 올려서 어느정도 피드백을 받을 수 있을것 같네요

추천
3

댓글 5개

1. 적극 동의 합니다.
  jwt를 쓰는 순간 그누보드 내부 로직을 많이 버려야 합니다.(그누보드는 사용자 임시 데이타를 세션에 저장하는 방식을 사용합니다.  실명인증 처리 등등.. 이 임시 데이타를 jwt에 토큰에 담게 되는데, 이게 사이즈도 커지고, 방법도 깔끔하지 않습니다. 세션만큼 깔끔한 인증처리 방식이 없어요.
가급적 session 으로 처리하고, session 으로 처리 안되면, server token + session,

이것저것 다 안되면, 프레임웍 쓰는게 정신건강상 좋을것 같습니다.
로직보다 구조에 더 신경을 써야 하는 상황이라 api를 왜 만들고 있을까 라는 자괴감 듭니다.

저도 주말에 작업중인거 정리한번 해봐야겠네요.
2. 의 경우는 캡챠도 캡챠지만, api limit를 설정할수 있도록 하는게 좋을것 같네요.
api 를 쓰면 아무래도 하나의 코드에서 이부분을 제어 할수 있게되니까,, 사이트마다 정책을 넣기 편할것 같네요.
문제가 되는건 역시 로그인 시도, 비밀번호 찾기 같은것일테니,, 특정 건수 이상 실패시, 건별로 대기시간을 점점 늘리는 방식이면 될것 같네요.
몇년간 운영한 영카트 기반 서비스의 앱 제작(flutter)을 앞두고 있는데,
API화에 대한 많은 고민와 노고를 느낄수 있네요..
이러한 노력들과 노력의 공유 덕분에 저같은 이제 막 발 담그려는 사람들에게 참 많은 도움이 되는 것 같습니다.
감사합니다. 코로나 조심하고 좋은하루되세요~
전체 96 |RSS
RESTful 내용 검색

회원로그인

진행중 포인트경매

  1. 참여1 회 시작24.03.28 11:15 종료24.04.04 11:15
(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT