http://www.die.net/musings/page_load_time/

우선 아래 내용을 써 놓았고

• IE, Firefox, Safari 는 HTTP Pipelining 을 기본적으로 제공해 주지 않는다. Firefox에선 세팅을 바꿀 수 있다.
• HTTP/1.1 권고안에서 한 도메인 당 커넥션은 2개로 제한한다. --> registry 수정을 통해서 변경 가능하다
• Upload와 download 속도가 다르다. --> ADSL같은 경우 특히 upload가 작죠.

에 대한 내용이 나와 있고,
아래 내용이 있는데

1. 외부 Object 에 대한 keep-alive 사용, 정확하게 이 말이 이해가 안되는데 (Turn on HTTP keepalives for external objects.) 3-way handshake를 줄일 수 있다는 내용인데...내용 자체는 keepalive를 당연히 5~10sec정도를 줘야 connection 트래픽을 감소 시킬 수 있다는 뜻. 적용하는게 퍼포먼스 측면에서는 좋으나 사용자가 정말 많은 사이트라면 고민을 해봐야 한다.
   
2. external object수를 줄여라. 당연한 얘기인데 ... 이번에 뼈저리게 느낀건데global reference가 되는 관계로 js, css include의 수를 줄이고 (하나 아님 2개로) request overhead 로 인해, 하나의 큰 파일이 두개의 작은 파일보다 더 빠르게 로딩된다. --> 이 말을 잘 봐야 하는데 대체가 가능할때 얘기다. 개체수가 200개 이상이고 여러 이미지를 묶어서 하나로 하는게 가능하다면 차라리 큰 게 낫다는 얘기다. CSS-base Design, CSS sprites등을 이용해 이미지 개체수를 줄인다.
3. 위 HTTP/1.1 권고안에서 한 도메인 당 커넥션은 2개로 제한한다. 의 내용을 보완하기 위해 버추얼 호스트 혹은 도메인 추가를 이용해서 여러개의 도메인을 사용하면 파이프라인 효과를 볼 수 있다.
   * 이 방법은 여러 이슈가 있을 수 있을텐데...임계치를 잘 봐야겠다.
   웹서버 CPU증가, DNS lookup 의 수 증가(이에 따른 트래픽)--> 개체수가 정말 많은 페이지에서 유용할 것이다. 또 유념할 것이 참 당기는 내용이긴 한데 yahoo의 테스트에선 파일 사이즈가 크다면 두개 정도가 적당하다고 테스트가 되어 있다. http://yuiblog.com/blog/2007/04/11/performance-research-part-4/ --> 공동구매 페이지 정도가 적당할 것으로 보인다.
4. stylesheets, javascript, images를 사용자 브라우저에 캐쉬 시켜라.
   변경될 경우를 고려해 디렉토리를 날자나 버젼별로 구분해서 관리하라. --> http://example.com/build/1235/logo.gif 관리가 만만치 않다. --> 정말 중요한 내용이다. js, css, image의 변경에 대한 지침을 가져가는 건 정말 중요하다. 다음에 웹을 만든다면 반드시 고려할 것이고 css, js는 gzip도 적용해야 한다. 도메인도 나누는 것이 좋겠다.
   이미지 url 에 쿼리 파라메터를 사용하지 마라. --> squid cache 서버가 인식하지 못 한단다.
5. 초기 메인 화면이나 많이 쓰이는 페이지에 대해서는 GET방식을 사용하고 정적페이지에  Last-Modified, ETag 를 이용하여 cache될 수 있도록 한다. --> 은근히 고민이 되는 부분이 있다.
6. HTTP request사이즈를 줄여라. cookie 밖에 없겠지. 쿠키 줄여야지. 별거 아닐 수 있다고 생각하겠지만 이미지가 캐싱이 안되어 있다고 하면 혹은 304라도 개체수만큼 날라간다.
7. http response도 줄여라. gzip의 활용. (html, css, js)
8. CDN의 고려. 당연히 좋을 수 있지.
9. 아파치 성능 고려.
   

좋은 내용이다.

스펙자체가 많이 이런 작업을 해본듯한데(그 회사에 들어간 개발자들이 기업 App. 경험이 충분한건지...)
반갑기도 하지만 요즈음 Spring이 java전체에 끼치는 영향이 너무 크다는 생각이 든다.

스프링배치 : http://blog.interface21.com/main/2007/05/07/spring-batch/ 

이걸 통해서 웹에 대해서 다시 한 번 생각을 하고 우리 App개발에서 되집어볼 요소를 생각해볼 수 있었음한다.

REST란 요즘에는 XML과 HTTP를 사용하는 웹기반인터페이스를 지칭(REST의 원칙을 따르는 웹서비스 혹은 URL구조)하는 것으로 굳어졌지만 원래는

웹과 같은 네트워크 시스템을 위한 원칙을 의미한다.

REST란 말을 그대로 해석한다면 구체적인 상태 전이로 할 수 있을텐데 이것은 웹시스템을 떠올리게 되면 네트워크가 있고

특정 웹에 사용자가 링크를 선택하게 되면 다른 페이지로 전이되는 모습을 설명한것이다.  (요청 --> 네트워크 --> 웹페이지 --> 전이 --> 다른 페이지)

REST에서 정의하는 주요 원칙은

- 클라이언트 서버(웹으로 보면 브라우저 / 웹서버) : Stateless

- 보편적인 인터페이스 (HTTP Method로 정의 된다. GET/POST/DELETE/PUT... )

- 자원은 URI를 통해 유일하게 지정된다.

- 각 자원들은 URI를 통해 서로 연결될 수 있다

 이 원칙들이 뭐 새로운 건 아니고 웹 자체가 만들어 질 때 설계가 된 것이고 이걸 잘 재정의한게 REST라고 할 수 있는데 몇가지 되집을게 있는데

REST에서 stateless 라면 즉 session, cookie는 사용하지 않는 것이 원칙이다. 이건 REST를 이용한 OPEN API에서 인증키라는 넘으로 표현한다. (매번 인증)

또 하나를 더 보면 웹에서는

GET : URI에 있는 자원 획득, select

POST : URI에 자원을 수용하도록 요구, insert

DELETE : URI의 자원 제거 , delete

PUT : URI에 자원을 위치 , update(어째 파일 업로드가 확 오긴 하지만...)

로 처음 디자인을 했는데 뭐 CRUD에 대한 내용에 대한 정의니까 당연한 디자인이겠지만 브라우저에서 GET/POST만 지원하는 것은

이것만으로도 충분하다고 생각도 된거기도 하고 GET은 조회, POST는 CUD의 역할을 한다고 디자인을 한 것이다.

* 조회하는 성격의 URL을 POST방식으로 하는 것은 웹의 디자인에도 유배될뿐만 아니라 stateless와 원래 용도를 이해한다면 브라우저에서 '만료된 페이지입니다'를 뿌리는 이유를 이해가 될 것이다.

GET의 제한이 있다고 ...조회용 URL을 POST로 한다는 것은 웹디자인상 편의상 규약상 하지말아야 할 일이고 가급적 나머지 등록 등은 POST로 해주는게 좋은 것이다.
전에 내가 이 얘기를 했을 때 누가 나한테 'insert후 결과값을 얻어서 POST 던져서 뿌려줘야 결과 처리 페이지는 어떻게 해요?' 라고 물은 적이 있었는데
당연히 key만 받아서 다시 얻어오는 것이 원칙이다. 주문 완료페이지는 주문 번호만 넘겨서 받아오던가...

(싸이마켓 초창기에 이렇게 되어 있는 것들이 많았지. 실패사례 중 하나)

이제 REST를 stateless와 Uniform interface라는 측면에서 구체적으로 보면서 RESTful App를 보면 다음과 같이 과장해서 정의를 할 수 있는데

HTTP method인 GET/POST/DELETE/PUT 와 리소스에 대한 URI의 결합으로 App의 동작을 정의하는 스킴으로 얘기할 수 있다.

예를 들면 만약 우리가 상품번호가 100번인 상품 정보를 상품정보를

조회 /item/item.do?method=doItemDetailView&goods_no=100 --> REST로 한다고 하면 /item/100 을 GET으로 요청
삭제 /item/item.do?method=doUpdateItem&goods_no=100 --> /item/100 DELETE으로 요청

이런식인데

언뜻 보면 URL의 의미가 명확해지는 듯 하기도 하고 모델만 잘 정의하면
(만약 신규 업무가 나온다고 하면 그 리소스에 대한 정의만 하면 되니까
e.g. 상품 일시 중지는 freeze라는 걸 정의하고 이런식으로 /item/100/freeze를 POST로 날리는 식으로, 삭제는 /item/100/delete 이렇게)
설계도 편하고 너무나 외부에 hackable한 제공을 해 줄 수 있게 보여쥴수 있죠.
(요즈음 블로그 URL을 보면 잘 따르고 있죠.
이 잘정리된 URL이 참 의미가 있는데 ... 웹이 링크로 움직이는 시스템이니까 더더욱 그런데
홈2의 게시물의 주소복사를 하면 이런식으로 되어있긴 한데...눈에 바로 보이는 링크는 이게 아니라서 -한번이라도 덜 타게 하려고 의도적으로 한건지는 모르겠지만
...요즈음 웹을 이렇게 만들면 욕먹는다는 거...우린 더 심하니까 할 말은 없고)

많이 샜는데 REST를 따르는게 많은 장점이 있을 듯 한데 적용하기를 가로막는 단점들이 있는데
일단 브라우저가 GET/POST외에 put/delete는 지원하지 않는다는거와 App의 복잡한 업무가 GET/POST/PUT/DELETE로 정의가 다 될수가 없기 때문에
당연히 custom method에 대한 리소스를 지원해야 하는데 보면...
아까 상품삭제를 /item/100 delete로 요청하는걸 /item/100?method=delete 로 한다고 하면...후자가 오히려 명확하게 보이기도 하고
웹 App의 복잡한 다 일일히 모델을 만들어줘야 하는데 이 작업이 비용이 많이 드는 작업이 되기 때문에 REST의 장점이 오히려
손실이 되기도 한다.

REST스런 App를 전면적으로 만드는건 참 힘들 수 있는 일이긴 하지만 분명
REST스런 App를 만들려고 하는 것은 장점이 많을 수 있고 설계를 하는데 유용한 컨셉이 될 것이다.

설계시
* unique URI
 - 리소스에 대한 정의(item, cart, coupon) + action(get/post/delete/put을 염두에 두고)
 - 설계한 모델의 리소스의 제대로 된 액션 정의. 만약 method가 getitem 인데 이걸 파라미터로 분기해서 다른 액션을 취하게 하는 건 틀린것이다.
* hackable URI
를 염두에 두고 하면 좋을 것이다

다음은 아마존의 REST방식 OPEN API중 장바구니 추가 예제인데 이걸 보면 좀 더 명확해질텐데
http://webservices.amazon.com/onca/xml?Service=AWSECommerceService&SubscriptionId=[Your
Subscription ID
Here]&Operation=CartAdd&CartId=[A Cart
ID]&HMAC=[An HMAC Shopping Cart
Token]&Item.1.ASIN=[An
ASIN]&Item.1.Quantity=1

여기서 subscriptionID는 --> 로그인을 위한 key(stateless)
Operation=CartAdd --> 리소스에 대한 action 정의

결과는 xml형식으로 return 된다.

아마존의 매출의 40%이상이 OPEN API에서 나오고 SOAP, REST방식으로 제공되는 OPEN API중에서
85%이상이 REST로 제공되고 있다.

국내에서는 옥션, GSeshop등이 SOAP으로 제공하고 있으나 별 의미 없는 상태이고
우리도 판매자 연동쪽에서는 OPEN API 제공 요구가 꾸준히 있다. 얼른 해야 할텐데...

참고 URL
http://www.awszone.com/
http://openapi.naver.com/index.nhn
http://www.restlet.org/ : Lightweight REST framework for Java