JSON REST/RPC 인터페이스 용 IDL

Question

대부분의 I/O가 특정 구조의 JSON으로 인코딩 된 객체 인 상당히 복잡한 REST API를 설계하고 있습니다. 우리가 발견 한 한 가지 문제점은 클라이언트가 올바른 입력 및 프로세스 출력을보다 쉽게 ​​게시 할 수 있도록 API를 문서화하는 것입니다. 입력 및 출력 데이터 모두 상당히 복잡한 JSON 객체가 필요하기 때문에 클라이언트 개발자는 종종 I/O 객체의 구조와 관련된 버그를 발생시킵니다.

요즘 모든 JSON 웹 API를 사용하면 일반적인 해결책을 기대했지만, 찾기가 어려울 것입니다. 나는 json-schema을 json-validation 스키마로 들여다 보았습니다. 그러나 IETF 초안과 구현은 상당히 미숙 한 것으로 보입니다 (잠시 동안 있었지만 좋은 징조는 아닙니다).

Protocol Buffers 및 Apache Avro으로 약간 다른 접근 방식이 제공됩니다. 스키마는 유효성 검사에 사용되지 않지만 실제로 메시지의 인코딩/디코딩에 필요합니다. 이 두 가지 중에서 Avro는 다소 제한된 문서 및 구현을 갖고있는 것으로 보입니다. ProtoBuf가 더 좋을 것으로 보이지만 브라우저에서 JSON API를 호출하는 데 정말로 적합한 지 확실하지 않습니다.

이제 저는 이것을 올바른 각도에서보고 있는지 의심 스럽습니다. 내 API를 좀 더 강력한 형식으로 만들 수있는 다른 방법이 있습니까? 또는 JSON REST/RPC API에 대한 공식적인 설명이 JSON 사용 목적을 상실한 것입니까?

편집 :이 주제가 나온 지 6 개월 후에 우리가 찾던 내용에 매우 근접한 mongoose이 발견되었습니다.

Answer 1

다음은 Douglas Crockford의 이메일로받은 답변입니다.

저는 입력 검증의 대안으로 스키마를 믿는 사람이 아닙니다. 구문에서 확인할 수없는 속성이 있습니다. 나는 이 XML이 잘못되었다고 생각했다.

형식이 너무 복잡하면 을 단순화합니다.

Answer 2

마지막 질문에 대한 답변이 '예'라고 말하고 싶습니다. JSON "스키마"를 제약하고 문서화 할 방법이 필요하다면 왜 XML을 사용하지 않았습니까? 구문 분석하는 것이 그리 어렵지 않으며이를위한 스키마를 적용 할 수 있다는 것이 큰 이점입니다.

Answer 3

XML은 여러 가지면에서 RESTful 서비스에 더 좋습니다. 네이티브 언어 지원 (<link href=, 모든 팬에게는 HATEOAS), 자국어 지원 (lang="en") 및 훌륭한 생태계가 있습니다.

향후 교정 및 향후 API 리팩토링에 더 좋습니다. 이 변환 :

<profile> 
    <username>alganet</username> 
</profile> 

더 많은 사용자 이름을 지원하기 위해 :

<profile> 
    <username>alganet</username> 
    <username>alexandre</username> 
</profile> 

하는 것은 기존 고객에게 사용하여 XML을 깨지 않고 을 할 훨씬 더 간단합니다. JSON은 그렇게 어렵습니다.

JSON이 정말로 필요한 경우 JSON 스키마를 사용하십시오. 아직 성숙하지는 않지만,이 경우 더 잘 알지 못합니다.어쩌면 소비자가 XML과 JSON 중 하나를 선택할 수 있으므로 Content Negotiation을 사용하여 작은 페이로드 (JSON) 또는 RESTful 사탕 (XML) 중에서 선택할 수 있습니다.

Answer 4

이러한 시스템이 존재하며 그 중 하나의 저자입니다. Piqi-RPC이라고하며 HTTP를 통한 RPC 스타일 API의 입력 및 출력 매개 변수에 대한 IDL 기반 유효성 검사를 수행합니다.

그것은 HTTP POST 요청의 입력 및 출력 데이터 표현 형식으로 JSON, XML 및 구글 프로토콜 버퍼를 지원

. 클라이언트는 세 가지 형식 중 하나를 사용하도록 선택하고 표준 Accept 및 Content-Type HTTP 헤더를 사용하여 선택을 지정할 수 있습니다.

그래서, 그래, 이론적으로, 당신은 올바른 방향으로 찾고 있습니다. 그러나 현재 Piqi-RPC는 Erlang에서만 서버 작성을 지원하며 다른 스택을 사용하면 유용하지 않습니다. Apache Thrift는 HTTP 전송을 통한 JSON도 지원한다고 들었지만 아직 확인하지 않았습니다. 내가 아는 비슷한 종류의 유사한 시스템 (Erlang의 경우)은 UBF입니다. JSON을 프로토콜 버퍼 사양 (예 : http://code.google.com/p/protostuff/)을 기반으로 구문 분석하고 유효성을 검사 할 수있는 Java 용 라이브러리에 대해 들어 봤습니다.

아이디어 자체는 지금까지 새로운 것을이지만, 실제로 그것을 접근 많은 시스템이 없습니다. 그것은 어려운 문제입니다.

역사적 IDLs는 인터페이스 정의 및 이진 데이터 직렬화에 사용 이상 출현 동적 데이터 교환 포맷 (예를 들면, XML 및 JSON)을 검증하기위한 것이 라기보다는 하였다. Sun-RPC IDL 및 CORBA IDL은 첫 번째 범주에 속합니다. WSDL은이 두 영역을 다루는 몇 가지 예 중 하나 일 것이지만, 이것은 기술의 끔찍한 부분이며 대부분의 최신 시스템에서 나쁜 선택이 될 것입니다. 또한 많은 스키마 언어 (DDL이라고도 함 - 데이터 정의 언어)가 있으며 대부분 특수화되어 있으며 하나의 표현 형식 만 사용합니다. XML 또는 JSON 스키마. 이들 중 일부는 안정적인 구현을 가지고 있습니다.

그것을 기반으로 Piqi project 및 Piqi-RPC는, 주변에 여러 상당히 간단 실현 구축됩니다

• DLL 명시 적으로 특정 데이터 표현 형식에 연결하거나 주변에 구축 할 필요가 없습니다를 그것. 대신, 그러한 언어는 상당히 보편적 일 수 있으며 사례 (예 : 언어 간 데이터 직렬화 및 데이터 유효성 검사) 및 데이터 형식 (예 : JSON, XML, 프로토콜 버퍼)과 같은 실제 사용 범위를 광범위하게 포괄 할 수 있습니다.

• IDL은 RPC 식 통신 범용 DDL 위에 얇은 주로 구문론 층으로 구현 될 수있다.

• 이러한 IDL 및 인터페이스 사양 전송 무관 할 수있다.

HTTP를 통한 RPC 스타일 API와 비교하여 HTTP를 통한 REST 스타일 API라고 말하면 당신이 그렇게 선택하면, 출력 (일부 서비스 이름 지정 방식에 따라) 함수 이름, 입력 :

RPC 스타일의 API를, 서비스 개발자 또는 자동화 된 시스템으로

세 가지를 확인해야합니다. REST 스타일의 API의 경우

, 사람들은 이유없이 곤경에 자신을 얻을. 이제 그들은 확인하기 위해 더 많은 물건을 가지고 : 동적 (모든 HTTP 메소드에 대한) URL 세그먼트에서 인코딩 된 매개 변수와 (단지 HTTP GET 방법) URL 쿼리 문자열, HTTP 방식의 대응 (를 포함하여 임의의 복잡한 URL 구문을, 그것을해야하는지 여부 GET, POST, PUT, DELETE 등), 일부 매개 변수가있을 때의 HTTP 본문 (JSON 및 XML에 표시된 매개 변수에 대해 수동으로 두 번 사용하는 경우도 있음), 사용자 정의 HTTP 헤더 및 개별 서비스 설명서. 모든 것을 지원하는 IDL을 상상해보십시오!