핸들러가 정의되지 않은 리소스에 요청이 들어왔을 때의 기본동작 (REST API)

[eungjun-yi]

핸들러가 정의되지 않은 리소스에 요청이 들어왔을 때의 기본동작이 구현되어있다면, 웹애플리케이션 만들때의 수고를 다소 덜어줄 수 있지 않을까 생각합니다.

GET /path/to/:container - 컨테이너가 갖고 있는 item들을 xml, json 등의 포맷으로 반환
DELETE /path/to/:container - 컨테이너 삭제
GET /path/to/:container/:id - 리소스 반환
PUT /path/to/:container/:id - 리소스 갱신(없다면 추가)
DELETE /path/to/:container/:id - 리소스 삭제
OPTIONS /* - 해당 리소스에 대해 사용할 수 있는 메소드들을 알려줌.

authentication/authorization을 어떻게 할지가 좀 고민이네요. OAuth를 구현해야하나?

[rampart81]

OAuth 를 위해 Joauth 를 써보는건 어떻까요? 트위터 에서 만든 스칼라 OAuth 라이브러리 인데 흥미로워 보입니다 ^^

https://github.com/twitter/joauth

[eungjun-yi]

@rampart81 오, 트위터에서 만든건가보네요. 신뢰가 좀 가는군요 :) 좋을 것 같습니다. 현대적인(?) 웹서버답게 Basic/Digest Authentication보다 OAuth를 먼저 기본으로 제공해주는 것도 좋을듯...

[eungjun-yi]

구현하다가 HTTP/1.1에 명확하게 정의되지 않아서 곤란한 부분이 있다면(예: POST), 우리가 직접 스펙을 쓰는 것도 괜찮겠네요. 물론 HTTP/1.1과의 호환성은 유지하면서...

[rampart81]

좋은 생각이네요 ^^ 저희가 직접 스펙까지 쓰다니 점점 더 흥미로워 지는데요 ^^

[eungjun-yi]

구글링을 좀 해보니, 일찌기 Roy Fielding 박사가 "HTTP object model" 이란 스펙을 쓰다가 잘 안된 과거가 있었던 모양이네요. http://permalink.gmane.org/gmane.comp.web.services.rest/3995

하지만 우리는 너무 많은 요구사항을 커버할 생각을 버리면 쓰는게 불가능하진 않을 것 같아요. webdav보다 훨씬 작고 느슨하게 가면 되지 않을까 싶네요.

[rampart81]

네 ^^ 처음에는 심플하게 시작해서 점차 발전시키면 좋을꺼 같아요 ^^