이것이“반 패턴”입니까? 사용을 중단해야합니까 아니면이 영리한 디자인입니까?


10

REST 서비스를 만들 때 기본적으로 다음을 수행하려고했습니다.

  1. HTML 요청
  2. 서비스는 요청한 "자원"없이 원하는 웹 페이지를 반환합니다 (예 : 데이터
  3. 웹 페이지에 AJAX 요청을 동일한 서비스 (다른 컨텐츠 유형)로 발행하는 JavaScript가 포함되어 있습니다.
  4. 그런 다음 서비스는 실제 데이터 (JSON)를 반환하고 페이지에이를 표시합니다

한쪽에서는 비효율적 (요청 2 건)으로 보였지만이를 사용했습니다. "성능은 중요하지 않습니다". 내부 트래픽이 적고 웹 사이트가 간단하고로드 속도가 빠릅니다.

내가 이것으로 끝내는 이유는 웹 페이지가 거의 순수한 Html + JavaScript 일 수 있으며 테이블과 물건을 만들기 위해 거의 루프가 필요하지 않은 서버 쪽 물건이 거의 없기 때문입니다. slickgrid와 같은 것), 예를 들어 데이터와 뷰의 분리.

이제 이것을 사용하기 전에 이것이 좋은 생각입니까, 아니면 그냥 그만해야합니까?


2
사랑하는 사람과 더 많은 시간을 보내고 취미 생활을 즐기거나 개인적인 목표를 추구하기 위해 자유 시간을 보내고 싶은 경우, 하나님을 위해 : 그런 응용 프로그램을 프로그래밍하지 마십시오! 그러나 사무실에서 밤과 주말에 늦게 머무르기를 원한다면 수많은 "영리한"코드를 유지해야합니다.
Tulains Córdova

3
당신이 잘못 생각하는 것을 구체적으로 설명 할 수 있습니까? 맥락 : 이것은 비즈니스에 중요한 10 Mio LOC 짐승이 아닙니다. <5000 LOC와 비슷하며 며칠 동안 작동하지 않더라도 상관 없습니다. 네, 그것은 엉뚱한 일을해서는 안됩니다. 그러므로 당신이 그렇게 나쁘다고 생각하는 것을 정교하게 만드십시오.
초보자

@begginer_ 모든 소프트웨어는 작게 시작합니다. 당신이 rseembles 루브 골드버그 머신 설명 : 망치 안타 사람은, 사람 비스킷, 앵무새 잡아 비스킷 상품 등 꽃병, 틸트
Tulains 코르도바

이 작업이 수행되는 이유는 종종 여러 서버에 대한 요청을 여러 번 동시에 요청하여 데이터를 페치 할 수있는 성능을 향상시키기 위해서입니다. 귀하의 경우에는 이것이 적용되지 않는 것 같습니다.
user16764

스크립트와 같은 클라이언트 또는 curl에서이 서비스를 어떻게 사용합니까? 그러한 것들에는 자바 스크립트 해석기가 없습니다. 브라우저 전용 서비스입니까?
Bryan Oakley

답변:


17

리소스를 요청했지만 리소스가 포함되어 있지 않은 경우 REST 서비스가 아닙니다. json에서 실제 데이터를 제공하는 서비스는있을 수 있지만 HTML 부분은 아닙니다. 웹 응용 프로그램의 경우 중요하지 않습니다.

이 기술은 효과가 있지만 제한 사항을 알고 있어야합니다.

  1. 검색 엔진은 자바 스크립트를 해석하지 않으므로 이와 같이 구현 된 사이트는 Google 등이 색인을 생성 할 수 없습니다. 내부 응용 프로그램의 경우 중요하지 않으며, 공개 응용 프로그램의 경우 중요합니다.
  2. 점자 터미널을 사용하는 사용자와 같이 특별한 요구가있는 사용자는 다소 제한적이고 JavaScript를 제대로 해석하지 못하는 특수 브라우저를 사용합니다.

또한 HTML을 생성하는 코드는 서버 측이든 클라이언트 측이든 상관없이 기본적으로 동일합니다. 서버 측에서 언어와 프레임 워크를 훨씬 더 많이 선택했으며 slickgrid와 동등한 몇 가지가 있다고 확신합니다.

서버 측에서 데이터 분리 및 표시를 계속 유지할 수 있고 유지해야합니다. 템플릿 시스템은 단순히 데이터 구조 또는 심지어 json (특히 실제 서비스가 템플릿 시스템과 다른 언어 인 경우)으로 데이터를 가져 와서 해당 데이터로 템플릿을 확장 할 수 있습니다.

그리고 아니요, PHP에 대해서는 생각하지 않습니다. 그것은 가장 능력이 뛰어난 템플릿 시스템입니다. Genshi 또는 XSLT 또는 웹 위젯을 제공하는 고급 기능을 생각하고 있습니다.


나는 정확하게 이것을하는 JavaScript로 팻 클라이언트를 작성합니다. 그러나 아마도 일반적인 웹 사이트에는 나쁜 생각 일 것입니다.
K ..

왜 REST가 아닌가?
dagnelies

1
애플리케이션을 형성하는 "데이터"(HTML, JS, CSS 등)와 애플리케이션이 표시하는 "데이터"(JSON)를 구별하는 경우 JSON 부분은 REST이지만 "코드"를로드하는 부분은 ' 티. 모든 것이 더 추상적으로 보이면 둘 다입니다.
K ..

2

코드를 깔끔하게 구성하는 한 아무런 문제가 없습니다. 웹 서비스가 아닌 Apache와 같은 정적 컨텐츠를 제공 할 수도 있습니다.


2
아파치는 정적 콘텐츠에 대한 과잉입니다. 훨씬 빠른 서버가 있습니다. 가장 인기있는 것은 Nginx 인 것 같습니다 .
Jan Hudec

5
그것은 하나의 예일뿐입니다.
Steven Schlansker

2

이것은 좋은 습관입니다. 그리고 @JanHudec이 지적한 것처럼 REST 서비스라고 잘못 말하면서 항상 끝났습니다. 그러나 많은 웹 사이트는 귀하가 지적한 이유로 정확하게 이것을 수행합니다.


1
... 그리고 큰 이유는 많은 데이터 상호 작용이 서비스를 통해이기 때문에 그것이 수행하는 것이 / JSON은 어쨌든 , 그래서 가능성이 더 나은 같은 방식으로 데이터의 모든 상호 작용을 처리 할 수 있습니다. (즉, AJAX를 사용하여 테이블을 새로 고치는 경우에도 테이블을 처음부터 빌드하는 데 사용해야합니다.)
Chad Thompson

@ChadThompson 그래, 처음에 이와 같은 것을 빌드 하지 않으면 많은 시간이 걸린다 것을 알았 습니다. 어딘가에서 클라이언트가 무언가를 수행하여 페이지를 동적으로 업데이트하는 기능 요청을 얻습니다. 이제 간단한 구현으로 클라이언트 서버 모두 페이지를 작성하는 방법을 알 수 있습니다. 먼저 클라이언트에서 빌드하는 것이 더 쉽습니다.
Tacroy

1

나는 그것을 반 패턴이라고 부르지 않을 것이다. 당신이 묘사하는 것은 Trello와 같은 서비스와는 달리 뚱뚱한 고객 이다. 서버의 초기 책임은 DOM 및 클라이언트 작동에 필요한 모든 리소스를 전송하는 것입니다. 데이터 센터 자동화 및 네트워크 모니터링에서 비슷한 프로젝트를 수행했습니다.

클라이언트는 스파 스 DOM으로 시작하여 XHR (때로는 JSONP를 통해)을 통해 일부 데이터를 가져 와서 마지막으로 소켓 서버에 연결합니다. 더 기본적인 예는 채팅 응용 프로그램입니다.

그렇게하지 않는 유일한 이유는 제대로 하기가 매우 어려울 수 있기 때문입니다. 비동기식 기능 프로그래밍과 모든 레이스 및 기타 문제에 익숙하다면 유지 관리에 아무런 문제가 없습니다. 더 중요한 것은 다른 사람들이 결국 그것을 유지할 수 있도록 작성하는 데 아무런 문제가 없다는 것입니다.

더 많은 기능을 추가하려는 생각이 겁나 기 시작하거나 디버깅이 악몽 인 것을 발견하기 시작하면 계속 실험하고 배우면서 프로덕션의 다른 방법을 고려할 수 있습니다.

자신을 위해 구멍을 파지 않는 한 유효한 디자인입니다. 깨끗한 인터페이스 대신 임의의 JS의 gob와 gob가 있다면 프로젝트를 다르게 리팩토링하거나 다른 방식으로 진행하고 싶을 것입니다. 모든 리소스로드가 한 번 실행되도록 정의 된 대부분 의 함수는 익명이어야하며 깨끗한 인터페이스에서 입력해야합니다. 그렇지 않은 경우 문제가 발생할 수 있습니다.


"무작위 JS"는 무엇을 의미합니까? 제 경우에는 위에서 설명 한 것이 훨씬 더 복잡합니다 (몇 가지 입력 필드와 테이블 (slickgrid) 또는 jquery ui 탭). 그게 다야. 페이지 당 약 200 LOC.
초보자

0

@Jan Hudec이 말했듯이 접근 방식을 REST라고 할 수는 없습니다. 클라이언트가 리소스를 요청하는 부분이 될 수 있습니다. 클라이언트가 프레젠테이션 부분을 처리하는 것이 좋습니다 backbone. 자원의 REST 서버와 통신하고을 사용하여 표시합니다 views.


0

안티 패턴 일 수도 있지만 웹 애플리케이션의 미래라고 생각합니다. 그러나 JavaScript를 사용하는 대신 최소한 템플릿 라이브러리를 사용해야합니다. 더 나은 솔루션은 AngularJS 와 같은 클라이언트 측 MVC 프레임 워크입니다 (지금 사용하고 있습니다).

더 많은 참고 자료를 위해 여러 프레임 워크를 비교 하는 인기있는 블로그 게시물 과 여러 프레임 워크를 사용하여 동일한 프로그램을 구현 하는 사이트 가 있습니다.

또한 : 검색 엔진 상호 작용 및 화면 판독기에 대한 Jan Hudec 의 의견이 유효합니다. 전자 상거래 사이트 (pagerank가 중요한 곳)에서 작업하고 있다면 클라이언트 측 프레임 워크를 사용하고 싶지 않을 것입니다. 그러나 내부 앱의 경우 일반적으로 걱정되지 않습니다.


thx는 AngularJS에 대해 들어 본 적이 없습니다. 그러나 나는 현재의 필요를 위해 그것이 너무 많다고 생각합니다.
초보자

0

당신의 일이 잘 들립니다! 그러나 json 응답에 HTML이 포함되어 있으면 시간 낭비입니다.

그럼에도 불구하고 바보 같은 클라이언트는 아마도 다른 프로젝트에서 json 데이터를 가져와야 할 것입니다. 당신은 클라이언트와 서비스를 적절히 분리하는 것을 목표로해야합니다. 그러면 당신은 적절한 RESTful 서비스를 갖게 될 것입니다

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.