¿Cuál es la necesidad de Odata cuando tengo JSON?

Estoy tratando de entender el punto de Odata y cuándo tendría sentido. En este momento, cómo trabajo es que uso ASP.NET y el controlador MVC / WebApi para serializar / deserializar objetos en JSON y hacer que JavaScript haga algo con él.

Por lo que puedo decir, el beneficio de OData es poder consultar directamente desde la URL ... Pero como estoy escribiendo el código del cliente y del servidor, no hay necesidad de eso.

¿Alguien analizaría los resultados de una consulta ODaya en javascript?

¿Quizás OData se trata más de proporcionar un punto final genérico para TODOS los clientes para obtener información detallada de una consulta que JSON no proporciona? Entonces, si fuera un proveedor de datos, entonces supongo que para eso están los odata.

Ayúdame a comprender el propósito y el uso de REST / JSON / ODATA.

JSON es solo un formato de intercambio de datos basado en JavaScript.

REST es un estilo de arquitectura, mientras que OData es una implementación específica de REST diseñada para generar y consumir datos, que admite dos formatos, AtomPub y JSON.

Entonces, la diferencia entre JSON con REST simple y OData son las opciones en OData para la manipulación de datos, por ejemplo, si consultamos datos usando el protocolo OData, podemos especificar las siguientes opciones en el URI,

• $ orderby
• $ top
• $ skip
• $ filtro
• formato $
• $ select

Podemos hacer proyecciones, vincular los recursos, etc. y todas estas opciones están disponibles de forma inmediata. Ahora imagine que si tuviéramos que proporcionar todas estas características en nuestro propio servicio REST, tendríamos que,

• Implementarlos todos
• Cree nuestra propia convención / palabras clave para diferentes operaciones

No solo es mucho trabajo, sino que también genera inconsistencias y crea una curva de aprendizaje para nuestros consumidores de datos.

La notación de objetos JSON o JavaScript es simplemente un formato o estándar para datos. Es un formato acordado para transmitir algo como un nombre de inicio de sesión O algo que debe ser consumido por un Servicio REST.

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

Aunque originalmente se deriva del lenguaje de script JavaScript, JSON es un formato de datos independiente del idioma, y ​​el código para analizar y generar datos JSON está fácilmente disponible en una gran variedad de lenguajes de programación.

No es parte de ningún lenguaje de programación en particular, por lo que diferentes sistemas pueden pasar datos con bastante facilidad, si saben que están usando JSON.

En cuanto a REST, es simplemente un estilo de arquitectura utilizado para servicios web.

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

Una forma de pensar en esto es si desea escribir un servicio web con el que muchas computadoras diferentes puedan comunicarse e intercambiar información. Puede escribir su servicio web para aceptar datos a través de la URL

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

La respuesta podría ser un objeto JSON que indica que se recibieron sus datos.

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

Nunca había oído hablar de OData, así que busqué en Google:

OData se basa en el protocolo AtomPub y JSON, donde la estructura Atom es el sobre que contiene los datos devueltos por cada solicitud de OData. Una solicitud OData usa el modelo REST para todas las solicitudes. Cada comando REST es una solicitud HTTP POST, GET, PUT, PATCH o DELETE (mapeo a CRUD) donde los detalles del comando están en la url.

OBTENER: Obtenga una colección de entidades (como documento de fuente) o una entidad única (como documento de entrada).

POST: crea una nueva entidad a partir de un documento de entrada.

PUT: Actualizar una entidad existente con un documento de entrada.

PATCH: actualiza una entidad existente con un documento de entrada parcial.

BORRAR: Eliminar una entidad.

Parece que OData es algo escrito para aumentar una arquitectura de estilo REST de vainilla ... Pero parece que puede darle algunas cosas adicionales para que pueda comenzar, en lugar de tener que escribir cosas desde cero en C # o cualquier lenguaje que esté usando.

Si su trabajo lo empuja a usar OData, todavía estaría usando JSON ... pero dentro del marco / estándar OData escrito por Microsoft et al.

¿Alguien analizaría los resultados de una consulta OData (sic) en javascript?

Sí, ya que (parece) está usando JSON. Sería perfectamente natural usar JS.

¿Quizás OData se trata más de proporcionar un punto final genérico para TODOS los clientes para obtener información detallada de una consulta que JSON no proporciona? Entonces, si fuera un proveedor de datos, entonces supongo que para eso es Odata.

Odata proporcionaría un servicio REST ... pero con algunos servicios estándar adicionales además de un punto final de servicio REST "genérico" simple ... a los clientes no les importa si estás usando OData o si estás rodando tu propio servicio C # ... siempre y cuando ya que las respuestas estaban en un formato acordado (como JSON). Sin embargo, para su trabajo tal vez quieran usar OData porque proporciona muchas características "listas para usar".

Para la pregunta "por qué", hay una muy buena definición en el libro RESTful Web APIs : esencialmente OData implementa un patrón de colección, donde una colección es un recurso que proporciona una lista de recursos a través de enlaces.

OData es una implementación específica del servicio RESTful con un estándar para la interfaz. La ventaja es cuando está exponiendo la API de su producto y dice que cumple con el estándar OData, ya que los usuarios que ya están familiarizados con OData pueden usarlo fácilmente sin pasar mucho tiempo leyendo la documentación de la API.

Desventaja: Si bien OData es excelente para exponer la base de datos subyacente, la especificación no incluye soporte para transacciones y no se puede usar en aplicaciones en las que podamos tener un servicio RESTful que sirva tanto como interfaz de base de datos como interfaz de transacción.