동사없이 REST URL을 만드는 방법은 무엇입니까?

https://stackoverflow.com/questions/1619152

06-07-2019
|

문제

편안한 URL을 설계하는 방법을 결정하기 위해 고군분투하고 있습니다. 나는 명사와 함께 URL을 사용하는 나머지 접근 방식을위한 것이며 동사는이 작업을 수행하는 방법을 이해하지 못합니다.

우리는 재무 계산기를 구현하기위한 서비스를 만들고 있습니다. 계산기는 CSV 파일을 통해 업로드 할 많은 매개 변수를 가져옵니다. 사용 사례는 다음과 같습니다.

새 매개 변수를 업로드하십시오
최신 매개 변수를 얻으십시오
주어진 비즈니스 날짜에 대한 매개 변수를 얻습니다
매개 변수 세트를 활성화합니다
매개 변수 세트를 검증하십시오

나머지 접근 방식은 다음과 같은 유형의 URL을 갖는 것입니다.

/parameters
/parameters/12-23-2009

처음 세 가지 사용 사례를 달성 할 수 있습니다.

게시물 요청에 매개 변수 파일이 포함 된 위치
첫 번째 URL을 얻습니다
두 번째 URL을 얻습니다

그러나 동사없이 4 번째와 5 번째 사용 사례를 어떻게 수행합니까? 다음과 같은 URL이 필요하지 않습니까?

/parameters/ID/activate
/parameters/ID/validate

해결책

아마도 : 아마도 :

PUT /parameters/activation HTTP/1.1
Content-Type: application/json; encoding=UTF-8
Content-Length: 18

{ "active": true }

다른 팁

좋은 URI 디자인을위한 일반적인 원칙 :

하지 않다 쿼리 매개 변수를 사용하여 상태를 변경하십시오
하지 않다 도와 줄 수있는 경우 혼합 경로를 사용하십시오. 소문자가 가장 좋습니다
하지 않다 URI (.php, .py, .pl 등)에서 구현 별 확장을 사용하십시오.
하지 않다 들어갑니다 RPC Uris와 함께
하다 URI 공간을 가능한 한 많이 제한하십시오
하다 경로 세그먼트를 짧게 유지하십시오
하다 둘 중 하나를 선호합니다 /resource 또는 /resource/; 사용하지 않는 301 개의 리디렉션을 만듭니다
하다 리소스의 하위 선택에 쿼리 매개 변수를 사용합니다. IE Pagination, 검색 쿼리
하다 HTTP 헤더 또는 몸에 있어야하는 URI에서 물건을 옮기십시오.

(참고 : 나는 "RESTFUL URI DESIGN"이라고 말하지 않았다. Uris는 본질적으로 휴식이 불투명하다.)

HTTP 방법 선택을위한 일반 원칙 :

하지 않다 상태를 바꾸는 데 사용하십시오. 이것은 Googlebot이 당신의 하루를 망치게하는 좋은 방법입니다.
하지 않다 전체 리소스를 업데이트하지 않는 한 Put 사용하십시오
하지 않다 합법적으로 동일한 URI를 얻을 수 없다면 풋 사용
하지 않다 게시물을 사용하여 오래 지속되거나 캐시에 합리적 일 수있는 정보를 검색합니다.
하지 않다 그렇지 않은 작업을 수행하십시오 Idempotent 풋으로
하다 최대한 많이 사용하십시오
하다 의심의 여지가있는 경우 우선적으로 게시물을 사용하십시오
하다 RPC와 같은 느낌을 줄 때마다 게시물을 사용하십시오.
하다 더 크거나 계층 적 자원의 클래스에 사용
하다 선호하는 삭제를 사용하여 자원을 제거하려면 게시하십시오
하다 입력이 크지 않으면 계산과 같은 항목을 사용하여 사용하십시오.

HTTP를 사용한 웹 서비스 설계의 일반적인 원칙 :

하지 않다 헤더에 있어야하는 응답의 본문에 메타 데이터를 넣으십시오.
하지 않다 상당한 오버 헤드를 생성하지 않는 한 메타 데이터를 별도의 리소스에 넣으십시오.
하다 적절한 상태 코드를 사용하십시오
- 201 Created 리소스를 만든 후; 자원 ~ 해야 하다 응답이 전송 될 때 존재합니다
- 202 Accepted 작업을 성공적으로 수행하거나 자원을 비동기로 작성한 후
- 400 Bad Request 누군가가 분명히 가짜 인 데이터에 대한 작업을 수행 할 때; 응용 프로그램의 경우 유효성 검사 오류가 될 수 있습니다. 가게되지 않은 예외를 위해 일반적으로 500을 예약하십시오
- 401 Unauthorized 누군가가 필요하지 않고 API에 액세스 할 때 Authorization 헤더 또는 자격 증명이있을 때 Authorization 유효하지 않습니다. 이 응답 코드를 사용하지 마십시오. Authorization 헤더.
- 403 Forbidden 누군가가 악의적 일 수 있거나 승인되지 않은 방식으로 API에 액세스 할 때
- 405 Method Not Allowed 누군가가 PIT를 사용했을 때 게시물을 사용하는 경우 등
- 413 Request Entity Too Large 누군가가 당신에게 용납 할 수없는 큰 파일을 보내려고 할 때
- 418 I'm a teapot 주전자로 커피를 양조하려고 할 때
하다 가능할 때마다 캐싱 헤더를 사용하십시오
- ETag 자원을 해시 값으로 쉽게 줄일 수있을 때 헤더가 좋습니다.
- Last-Modified 리소스가 업데이트 될 때의 타임 스탬프를 유지하는 것이 좋습니다.
- Cache-Control 그리고 Expires 현명한 값을 주어야합니다
하다 요청에서 캐싱 헤더를 기리기 위해 할 수있는 모든 것 (If-None-Modified, If-Modified-Since)
하다 의미가있을 때 리디렉션을 사용하지만 웹 서비스에는 드물어야합니다.

특정 질문과 관련하여 게시물은 #4 및 #5에 사용해야합니다. 이러한 작업은 위의 "RPC와 같은"지침에 속합니다. #5의 경우 게시물이 반드시 사용할 필요는 없다는 것을 기억하십시오. Content-Type: application/x-www-form-urlencoded. 이것은 쉽게 JSON 또는 CSV 페이로드 일 수 있습니다.

새로운 동사가 필요한 것처럼 보일 때마다 대신 동사를 명사로 바꾸는 것을 생각해보십시오. 예를 들어 '활성화'를 '활성화'로 바꾸고 '검증'을 '검증'으로 바꾸십시오.

그러나 당신이 쓴 것만으로도 당신의 응용 프로그램은 훨씬 더 큰 문제가 있다고 말합니다.

'매개 변수'라는 리소스가 제안 될 때마다 모든 프로젝트 팀원의 마음에 적기를 보내야합니다. '매개 변수'는 문자 그대로 모든 리소스에 적용될 수 있습니다. 충분히 구체적이지 않습니다.

'매개 변수'는 정확히 무엇을 나타 냅니까? 아마도 여러 가지 다른 것들이있을 것입니다. 각각은 별도의 자원이 있어야합니다.

이를 얻는 또 다른 방법 - 최종 사용자 (아마도 프로그래밍에 대해 거의 알지 못하는 사람들)와 응용 프로그램을 논의 할 때 자신이 반복적으로 사용하는 단어는 무엇입니까?

그것들은 당신이 당신의 응용 프로그램을 설계 해야하는 단어입니다.

아직 예비 사용자 와이 전환을하지 않았다면 지금 당장 모든 것을 중지하고 할 때까지 다른 코드 라인을 작성하지 마십시오! 그래야만 팀은 무엇을 구축 해야하는지에 대한 아이디어가 있습니다.

나는 금융 소프트웨어에 대해서는 아무것도 모르지만 추측해야한다면 자원 중 일부는 "보고서", "지불", "전송"및 "통화"와 같은 이름으로 갈 수 있다고 말할 것입니다.

소프트웨어 디자인 프로세스 의이 부분에는 많은 좋은 책이 있습니다. 내가 추천 할 수있는 두 가지 도메인 구동 설계 그리고 분석 패턴.

URL의 디자인은 응용 프로그램이 편안한 지 여부와 관련이 없습니다. 따라서 "편안한 URL"이라는 문구는 말도 안됩니다.

나는 당신이 실제로 어떤 것이 무엇인지에 대해 더 읽어야한다고 생각합니다. 휴식은 URL을 불투명 한 것으로 취급하므로 동사 나 명사 등에 관계없이 그 안에 무엇이 있는지 알지 못합니다. 여전히 URL을 설계하고 싶을 수도 있지만 휴식이 아니라 UI에 관한 것입니다.

즉, 마지막 두 경우는 편안하지 않으며 어떤 종류의 편안한 계획에 맞지 않습니다. 그것들은 당신이 RPC라고 부르는 것입니다. 휴식에 대해 진지하게 생각하면 응용 프로그램이 처음부터 어떻게 작동하는지 다시 생각해야합니다. 그 중 하나 또는 휴식을 포기하고 앱을 RPC 앱으로 수행하십시오.

hrmmm 아마 아닐 수도 있습니다.

여기서 아이디어는 모든 것을 리소스로 취급해야한다는 것입니다. 따라서 매개 변수 세트에 URL이 있으면 참조 할 수 있습니다.

ParametersUrl]/validationResults를 얻으십시오

게시 [paramatersurl

바디 : {명령 : "활성화"}

그러나 다시, 그 활성화는 RPC입니다.

요구 사항은 활성화 및 검증 요구 사항은 자원 상태를 변경하려는 상황입니다. 주문을 "완료"하거나 다른 요청을 "제출"하는 것도 다르지 않습니다. 이러한 종류의 상태 변화를 모델링하는 방법에는 여러 가지가 있지만 종종 효과가있는 것은 동일한 상태의 리소스를위한 컬렉션 리소스를 만들고 컬렉션간에 자원을 이동하여 상태에 영향을 미치는 것입니다.

예를 들어

/ActiveParameters
/ValidatedParameters

매개 변수 세트를 활성화하려면 해당 세트를 ActiveParameters 컬렉션에 추가하십시오. 매개 변수 세트를 엔티티 본체로 전달하거나 다음과 같이 URL을 쿼리 매개 변수로 전달할 수 있습니다.

POST /ActiveParameters?parameter=/Parameters/{Id}

/ValidatedParameters에서도 동일한 작업을 수행 할 수 있습니다. 매개 변수가 유효하지 않은 경우 서버는 "불량 요청"을 요청에 반환하여 검증 된 매개 변수 모음에 매개 변수를 추가 할 수 있습니다.

다음 메타 리소스와 방법을 제안합니다.

매개 변수를 활성화하고/또는 검증하십시오.

> PUT /parameters/<id>/meta HTTP/1.1
> Host: example.com
> Content-Type: application/json
> Connection: close
>
> {'active': true, 'require-valid': true}
>
< HTTP/1.1 200 OK
< Connection: close
<

매개 변수가 활성화되고 유효한지 확인하십시오.

> GET /parameters/<id>/meta HTTP/1.1
> Host: example.com
> Connection: close
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Connection: close
<
< {
<     'active': true,
<     'require-valid': true,
<     'valid': {'status': false, 'reason': '...'}
< }
<

휴식 환경에서 각 URL은 고유 한 리소스입니다. 당신의 자원은 무엇입니까? 재무 계산기에는 실제로 명백한 자원이 없습니다. 매개 변수를 호출하는 것을 파고 리소스를 꺼내야합니다. 예를 들어, 대출에 대한 상각 달력은 자원 일 수 있습니다. 캘린더의 URL에는 start_date, 용어 (개월 또는 YERS), 기간 (이자가 복합), 이자율 및 초기 원칙이 포함될 수 있습니다. 모든 값을 사용하면 특정 지불 일정이 있습니다.

http://example.com/amort_cal/2009-10-20/30yrsfixed/monthly/5.00/200000

이제 당신이 무엇을 계산하는지 모르겠지만 매개 변수 목록의 개념은 편안하게 들리지 않습니다. 다른 사람이 말했듯이, 당신의 요구 사항은 더 많은 xmlrpc 소리를냅니다. 휴식을 위해 노력하고 있다면 명사가 필요합니다. 계산은 명사가 아니며 명사에 작용하는 동사입니다. 계산서에서 명사를 꺼내려면 돌려 놓아야합니다.

편집하다: 실제로 URI는 예방했을 것입니다 GET 나머지 idempotent의 요청.

그러나 유효성 검사의 경우 HTTP 상태 코드를 사용하여 요청의 유효성을 알리면 (새 '매개 변수를 수정하거나 기존'매개 변수를 수정하기위한)는 편안한 모델에 적합합니다.

다시보고하십시오 400 Bad Request 제출 된 데이터가 유효하지 않은 경우 상태 코드는 다시 제출되기 전에 요청을 변경해야합니다 (HTTP/1.1 상태 코드).

이는 사용 사례에서와 같이 연기하지 않고 제출 시간에 검증하는 데 의존합니다. 다른 답변에는 해당 시나리오에 대한 적절한 솔루션이 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow