Qual é a necessidade do Odata quando eu tenho o JSON?

Estou tentando entender o ponto de Odata e quando faria sentido. No momento, como trabalho é usar o controlador ASP.NET e MVC / WebApi para serializar / desserializar objetos em JSON e fazer com que o javascript faça alguma coisa com ele.

Pelo que posso dizer, o benefício do OData é poder consultar diretamente a partir da URL ... Mas, como estou escrevendo o código do cliente e do servidor, não há necessidade disso.

Alguém já analisou os resultados de uma consulta ODaya em javascript?

Talvez o OData tenha mais a ver com fornecer um terminal genérico para TODOS os clientes para obter informações detalhadas de uma consulta que o JSON não fornece? Então, se eu era um provedor de dados, suponho que é para isso que serve o odata?

Ajude-me a entender a finalidade e o uso do REST / JSON / ODATA.

JSON é apenas um formato de intercâmbio de dados baseado em JavaScript.

REST é um estilo de arquitetura, enquanto OData é uma implementação específica do REST projetada para gerar e consumir dados, que suporta dois formatos, AtomPub e JSON.

Portanto, a diferença entre JSON com REST e OData simples são as opções no OData para manipulação de dados. Por exemplo, se consultarmos dados usando o protocolo OData, podemos especificar as opções abaixo no URI,

• $ orderby
• $ top
• $ pular
• $ filter
• formato $
• $ select

Podemos fazer projeção, vincular os recursos etc., e todas essas opções estão disponíveis imediatamente. Agora imagine se tivéssemos que fornecer todos esses recursos em nosso próprio serviço REST, teríamos que,

• Implementar todos eles
• Crie nossa própria convenção / palavras-chave para diferentes operações

Não é apenas muito trabalho, mas também leva a inconsistências e cria uma curva de aprendizado para nossos consumidores de dados.

JSON ou JavaScript Object Notation é apenas um formato ou padrão para dados. É um formato acordado para transmitir algo como um nome de login OU algo que precisa ser consumido por um serviço REST.

Veja esta parte: http://en.wikipedia.org/wiki/JSON

Embora originalmente derivado da linguagem de script JavaScript, o JSON é um formato de dados independente da linguagem, e o código para analisar e gerar dados JSON está prontamente disponível em uma grande variedade de linguagens de programação.

Não faz parte de nenhuma linguagem de programação específica; portanto, sistemas diferentes podem transmitir dados com bastante facilidade, se souberem que estão usando JSON.

Quanto ao REST, é simplesmente um estilo de arquitetura usado para serviços da web.

Veja esta parte: http://en.wikipedia.org/wiki/Representational_state_transfer

Uma maneira de pensar sobre isso é se você deseja escrever um serviço da Web com o qual muitos computadores diferentes possam conversar .. e trocar informações. Você pode escrever seu serviço da web para aceitar dados via URL

 http://www.myservice.com/specialRESTService?name=punkouter

A resposta de volta pode ser um objeto JSON sinalizando que seus dados foram recebidos.

{
    "name": "punkouter",
    "status": "service downloaded your data",
}

Eu nunca tinha ouvido falar do OData, então pesquisei no Google:

O OData é criado no protocolo AtomPub e JSON, em que a estrutura Atom é o envelope que contém os dados retornados de cada solicitação OData. Uma solicitação OData usa o modelo REST para todas as solicitações. Cada comando REST é uma solicitação HTTP POST, GET, PUT, PATCH ou DELETE (mapeamento para CRUD) em que os detalhes específicos do comando estão no URL.

GET: obtenha uma coleção de entidades (como um documento de feed) ou uma única entidade (como um documento de entrada).

POST: Crie uma nova entidade a partir de um documento de entrada.

PUT: atualiza uma entidade existente com um documento de entrada.

PATCH: Atualize uma entidade existente com um documento de entrada parcial.

DELETE: remova uma entidade.

Parece que OData é algo escrito para aumentar uma arquitetura de estilo REST baunilha. Mas parece que isso pode lhe dar algumas coisas adicionais para ajudá-lo, em vez de precisar escrever coisas do zero em C # ou em qualquer idioma que você esteja usando.

Se você trabalha para empurrá-lo para o uso do OData, você ainda está usando o JSON..mas dentro da estrutura / padrão do OData escrito por Microsoft et al.

Alguém já analisou os resultados de uma consulta OData (sic) em javascript?

Sim, já que (parece) ele está usando JSON. Seria perfeitamente natural usar JS.

Talvez o OData tenha mais a ver com fornecer um terminal genérico para TODOS os clientes para obter informações detalhadas de uma consulta que o JSON não fornece? Então, se eu era um provedor de dados, suponho que é para isso que serve o Odata?

Odata estaria fornecendo um serviço REST .. mas com alguns serviços padrão adicionados sobre um terminal de serviço REST "genérico" simples. Os clientes não se importam se você estiver usando OData ou executando seu próprio serviço C #. como as respostas estavam em um formato acordado (como JSON). No entanto, para o seu trabalho, talvez eles desejem usar o OData porque ele fornece muitos recursos "prontos para uso".

Para a pergunta "por que", há uma definição muito boa no livro RESTful Web APIs - essencialmente o OData implementa um padrão de coleção, em que uma coleção é um recurso que fornece uma lista de recursos por meio de links.

OData é uma implementação específica do serviço RESTful com um padrão para interface. A vantagem é quando você expõe a API do seu produto e diz que é compatível com o padrão OData, pois os usuários já familiarizados com o OData podem usá-lo rapidamente, sem gastar muito tempo lendo a documentação da API.

Desvantagem: Embora o OData seja excelente em expor o banco de dados subjacente, a especificação não inclui suporte para transações e não pode ser usado em aplicativos em que podemos ter um serviço RESTful servindo como interface de banco de dados e como interface de transação.