Pergunta

Se bem entendi, no estilo de resto, cada consulta (ou seja, cada ação em cada recurso que não modifica o estado do recurso) devem ser codificados na cadeia de consulta, utilizando um método get, sem corpo em tudo.

Am I certo?

Bem, eu tenho vários aplicativos que se comunicam com a db através de uma mensagem XML que é tratado por um componente Visual Basic 6.

a mensagem para uma consulta é algo como isto

<xml>
  <service>account</service>
  <resource>invoice</resource>
  <action>query</action>
  <parameters>
    <page>1</page>
    <page_len>10</page_len>
    <order>date</order>
    <fields>*</fields>
    <conditions>
      <date>2009-01-01..2009-01-31</date>
      <customer_id>24</customer_id>
    </conditions>
  </parameters>
</xml>

Agora nós estamos no processo de redesenhar nossas mensagens XML, e nós gostaríamos de fazer isso de tal maneira que eles poderiam ser facilmente mapeada para uma interface RESTful.

No exemplo anterior, temos as "condições" tags para evitar colisões entre os parâmetros e as condições (ou seja, o que acontece se eu tiver um campo chamado "ordem", "página" ou algo parecido .. .

Nós embora sobre o envio dos parâmetros com um prefixo, algo como

http://account/invoice/?_page=1&_page_len=10&_order=date&_fields=*&date=2009-01-01..2009-01-31&customer_id=24

eo XML seria algo como

[...]
    <_order>date</_order>
    <_fields>*</_fields>
    <date>2009-01-01..2009-01-31</date>
    <customer_id>24</customer_id>
[...]

Estamos tentando definir algum formato XML muito simples para operações CRUD, e que o XML resultante poderia ser facilmente mapeados para descansar ou JSON.

Como você mapear esse tipo de consulta em um aplicativo do resto? Existe algum padrão definido? ou alguma página com XML amostras CRUD REST / / JSON? como sobre o retorno de erro, ou conjuntos de dados aninhadas?

Muito obrigado.

Foi útil?

Solução

IMHO, a fim de tornar o sistema verdadeiramente RESTful você deve repensar todas as mensagens / consultas que você vai enviar.

Esta parte:

<conditions>
  <date>2009-01-01..2009-01-31</date>
  <customer_id>24</customer_id>
</conditions>

é a parte complicada. Que tipo de outras condições que você tem? Há muitos? Este exemplo em particular me faz pensar que você pode tratar faturas como um subrecurso de um cliente. Quando eu faço descansar Eu sempre tentar identificar recursos no caminho e se um stil consulta precisa quaisquer parâmetros, eu movê-los para string de consulta. Então eu ia escrever algo como isto:

GET /customers/24/invoices?start_date=2009-01-01&end_date=2009-01-31

Pense sobre as relações entre seus recursos. Vamos dizer que temos tipo de recurso Foo tipo de recurso relacionado Bar por uma relação -para-muitos. Neste caso, você pode perguntar sobre essa relação como esta: parâmetros GET /foo/123/bar e cadeia de consulta add para filtrá-lo. O problema começa quando você quer filtrá-la de uma forma que envolve relações com outros recursos. IMHO isso significa que seu projeto recurso não é verdadeiramente RESTful.

Outras dicas

Você precisaria url-codificar o XML para ser capaz de passá-lo, mas, se você converteu o XML para JSON, então você pode passar essa string e então json-> xml ou json-> objeto para processá-lo. Isso permitirá que você para passar objetos mais complexos ao redor.

Não é perfeito, mas funciona. :)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top