이것이 올바른 REST 구현입니까?

Question

저는 API의 리소스를 꾸준히 구축했지만, RESTful API를 빌드하는 정확한 방법에 대한 많은 연구를 거쳐서 '복잡한'요청을받는 방법의 예를 찾을 수 없었습니다. 예를 들어

(인증 키 갱신에 불과하다) 로그인 프로세스의 일부로서, 다음 URI는 클라이언트로 전달됩니다 :

/api/auth/login 

이 URI에 아무런 값이 없습니다는 리소스는 /auth/이고 트리거되는 명령은 /login/입니다. 실제 로그인 세부 사항은 서버 권한 부여 헤더로 보내집니다.

이제이 질문에 대한 질문을 던졌습니다. 클라이언트가 키의 유효 기간을 알려주는 명령을 작성한 것이므로 즉시 명령 이름과 비슷한 getkeyexpiration으로 그려졌습니다. .

갑자기 나는 이것이 6 제약에서 읽은 것처럼 들리지 않는다고 느꼈다. 이것은 조작 호출과 비슷하다고 느낀다.

위 예제를 기반으로해도 여전히 RESTful API입니까? 단순히 URI 리소스 이름과 추가 된 값을 사용하여이 작업을 수행 할 수있는 방법을 생각할 수 없기 때문에 걱정됩니다. 서버가 작동하는 방법의 맥락이된다 http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http 이해하기 시작하고

그 명사 단어 자원과 자원 만 이름을 지정하여이 읽기에서

:

는

EDIT 감사 훨씬 더 명확 해. 내 위의 예에 대해서는

은

: 그 자원의 컨텍스트이기 때문에

/api/auth/login 

나는, 로그인의 접두사로 인증 사용했다. 내 시스템을 확장 가능하도록 설계 중이며 URI 수준에서 자원을 분류하는 방법이 필요합니다. 이 작업을 수행하는 표준 방법이 있습니까?

Answer 1

HTTP가 동사를 제공하므로 RESTful 리소스는 명사이어야합니다.

나는이 대신 같은 것을 제안 :

/api/key 

어떤 할 수 있습니다 다음 POST에 (HTTP 권한 부여 헤더를 포함하여),이 같은 반환 뭔가 새로운 키를 만듭니다

/api/key/1234ABCDBLAHBLAH 

이를 세션에 고유 한 키입니다. 그런 다음 만료 시간 등과 같은 세부 정보를 검색 할 수 있습니다. 그런 다음 각 요청에 대해 해당 키를 전달해야합니다.

RESTful API의 컨텍스트에서 논의 할 때 핵심 요소가 거슬리는 소리로 들린다면 그것은 일반적으로 그렇기 때문입니다. 세션은 사람/브라우저 개념이지만 RESTful API는 응용 프로그램/통합 개념입니다.

서버는 다른 서버에 "로그온"하지 않으므로 다음과 같은 질문을 던집니다. 호출자가 Auth 헤더를 로그인 API에 전달해야하는 경우 이미 괜찮 으면 각 API 호출, 그리고 키의 개념을 모두 잊어 버리시겠습니까?