* .local 서비스 URL은 RESTful입니까?

URL은 리소스를 찾아서 (단순히 식별하지 않고) 가정합니다. 동일 URL은 동일한 자원을 참조해야한다는 결론이 나옵니다. 그러나 http://api.local/orders/333과 같은 URL에서는 api.local이 모든 사용자를위한 호스트로 확인되지 않고 해결되는 경우 동일한 호스트로 확인되지 않을 수도있는이 규칙은 위반 된 것으로 보입니다. (예를 들어, 실제 환경에서 하나 개의 개발 환경에서 호스트, 다른에서 api.local 가리킬 수 있습니다.) * .local 서비스 URL은 RESTful입니까?

는 엄밀히 말하면, api.local (또는 127.0.0.1) 편안하고 같은 호스트 이름과 URL은?
이 접근 방식으로 인해 발생할 수있는 문제가 있습니까?
좋은 대안이 있습니까? (어떤은 더 나은 : http://flickr/ 또는 http://flickr.local/ 또는 http://flickr.api)

출처

2010-06-24 mjs

URL은 RESTful이 아닙니다. 응용 프로그램은 RESTful (또는 아님)이지만 URL은 그렇지 않습니다. 사실, RESTful 애플리케이션에서 URL은 완전히 관련이 없으므로 URL이 RESTful인지 여부에 대해 걱정하는 단순한 사실은 애플리케이션이 아니라는 것을 보여준다. 하지만 URL과 관련이 없습니다.

출처

2010-06-24 04:27:56

URL이 RESTful이 아닌 좋은 지적입니다. 어쩌면'* .local' URL을 URL이라고 부를만한 가치가 있는지 궁금 할 것입니다. (그리고 나는 이것이 매우 궁금한 질문입니다!) 아마도 URL에 대한 규칙은 실제로는 전역 적으로 적용되는 것이 아니라 각 응용 프로그램의 영역 내에 있습니다. 즉 URL은 애플리케이션 자체 내의 리소스를 찾습니다. 그러나 다른 애플리케이션은 'api.local'이 다른 곳에서 해석된다는 것을 결코 알지 못하기 때문에 동일한'api.local'을 참조 할 수 있고 다른 것을 의미 할 수 있습니다. – mjs

URL은 해당 자원에 액세스하는 데 사용할 해당 자원과 프로토콜의 경로를 지정하여 자원을 찾습니다. 모든 예제는 똑같이 RESTful이다. REST 클라이언트가 액세스하려고하는 REST 클라이언트에 상대적인 자원을 식별합니다.

REST 클라이언트는 액세스하려는 리소스의 위치를 자유롭게 지정할 수 있습니다. REST 클라이언트는 api.local 서버에 액세스하려는 리소스를 포함하거나 포함하지 않음을 알 수 있어야합니다.

REST 서버에서 보편적으로 액세스 할 수있는 리소스를 사용하려는 경우 올바른 URL을 묻는 경우가 아니면 리소스를 찾을 수 없습니다.

로컬 컴퓨터에 REST 서버가 있고 인터넷에 다른 서버가있는 상황을 생각해보십시오. REST 클라이언트는 그가 액세스하고자하는 것을 지정합니다.

동일한 리소스를 참조하는 여러 URL을 갖는 것이 최선의 설계는 아니라고합니다. 따라서 api.local을 사용할 때 아무런 문제가 없지만 api.local 및 api이 다른 리소스를 참조 할 때 허용하는 것이 좋습니다.

출처

2010-06-24 01:10:24

URL은 "유니폼 리소스 로케이터"이며 "유니버셜 리소스 로케이터"가 아닙니다. URL에는 "전 세계적으로"또는 "보편적으로"액세스 할 수 있어야한다는 암시가 없습니다. 그래서 로컬 테스트를 위해 * .local에 문제가있는 것을 보지 못했습니다. (확실히 에서 액세스 할 수있는 테스트 또는 개발 환경을 갖고있는 것이 나쁠 것 같습니다.)

출처

2010-06-24 01:12:22

전 세계적으로 보편적으로 액세스 할 필요가 있다고 생각하지 않지만 같은 URL이 항상 같은 것을 참조해서는 안됩니까? (액세스 가능 여부와 상관없이) – mjs

아, 나는 당신이 말하는 것을 보았습니다. 한 컴퓨터의 "xyz.local"은 다른 컴퓨터의 "xyz.local"과 다른 의미를 가질 수 있습니다. 나는 가장 엄격한 의미에서 그렇다고 생각 합니다만, 실용주의적인 관점에서 볼 때 항상 가능한 것은 아닙니다. –

캐시에 대한 영향 때문에 "하나의 URL 만 리소스를 반환해야합니다."의 주요한 실질적인 문제 중 하나입니다. 동일한 리소스에 대해 두 개의 URL이있는 경우 캐시에 두 개의 복사본을 만들 수 있습니다. 둘 중 하나에 PUT을 수행하면 캐시는 두 가지 모두를 무효화해야하지만 두 사본 간의 관계에 대해서는 알지 못합니다.

중간 참조를 사용하는 위치에 따라 다른 바이트 스트림으로 해석 될 수있는 호스트 이름을 사용하는 문제와 관련해서는 전혀 문제가되지 않습니다. 개념적으로 동일한 리소스에 액세스하고 있으며 실제로는 그 리소스의 다른 인스턴스입니다. 나는 이것을 발견 메커니즘의 한 형태로 광범위하게 사용한다. "TMServer"라는 별칭을 가진 서버에서 호스팅되는 엔터프라이즈 응용 프로그램을 개발합니다. 조직 내에서 TMServer 인스턴스는 하나만 존재하며 해당 호스트에서 모든 리소스에 액세스합니다. 예 :http://TMServer/Suppliers 내 다른 고객 중 하나에서 동일한 URL은 완전히 다른 공급 업체 세트로 해결되지만 여전히 개념적으로 "공급 업체 목록"입니다.

고객 중 한 명이 다른 회사와 URL을 공유하려고 시도하는 경우 URL을 http://TMServer.company.com/Suppliers과 같이 확장해야합니다. 이것은 보편적으로 고유 한 URI가됩니다.

DNS 별칭을 사용하면 .hosts 파일을 사용하여 테스트를 위해 TMServer가 가리키는 위치로 쉽게 리디렉션 할 수 있으며 DNS 서버에 항목을 추가하여 네트워크의 모든 사용자에게 서비스 가용성을 브로드 캐스트 할 수 있습니다.

출처

2010-06-24 01:41:07

* .local 서비스 URL은 RESTful입니까?

답변

관련 문제