I have a recurring problem with single-item json data sources that are consistently rejected by a C data parser looking for the parent/child structure of a multi-item feed.
Where is it easiest to fix this - on my end, when I create the feeds, or for the C programmer to add a couple lines to also let it accept data that looks like object?
The error message I get is
Cannot access child value on Newtonsoft.Json.Linq.JProperty
which tells me it looks around the house for children that don't exist, like a nosy aunt.
In case you need to know how the data is processed, I use yql to standardize various sources so the parser can import everything into the right MongoDB fields. Everything is generated dynamically a few times a day and I can't do anything about the sources that will only deliver one update at a time.
Here's an example of json rejected because it looks like an object.
{"item":
{
"artist":"Morphine",
"song":"Thursday",
"station":"WXXX",
"feeddate":"1438014574000",
"dttype":"utc"
}
}
The one whose fault it is, has to fix it. Simple. Look up the specification what you are allowed to pass to the parser.
Related
I am parsing an XML document to JSON, and eventhough I have the type array declared in the json schema, if there is just one element in the array it gets transformed into an objet like this.
"ListOfCodes":{"Codes":{{"Code":"111"}}}
but I need this:
"ListOfCodes":{"Codes":[{"Code":"111"}]}
I have several arrays in the document and I only get the sqare brackets when there is a multiple array.
and adding the properties manually is not an option.
Anyone know what can i modify to fix this in the logic app?
Unfortunately, there isn't a good solution for us to implement this requirement in logic app. Here is another post which is similar to your problem. To implement the requirement, we can just:
1. Use the "Compose" action to generate the object by hand (manually put all the properties and arrays where they need, potentially using the #array() action.
2. Call an Azure Function or some external code that can more specifically craft a valid JSON.
I also try to test it in some other way, such as use json:Array="true" and use <?xml-multiple?> but they all fail in logic app. So I think the only above two solutions(mentioned in that post) can be used. Neither approach is good, though.
In order to reduce response time or to shorten time that the user waits for data when rendering views, i'm trying to determine what's best in interacting with a REST API. I'll be getting an array of items with 5-7 fields, e.g. name, title, imgUrl. I can either make one big call and traverse through the response to get the data that I need or make 5-7 requests to get the exact information that I need.
There are two issues with making the large call.
ALOT of data is returned with each item. I tested with retrieving 3 items and it took about 899 ms.
The fields that I need cannot simply be referenced by a key. Each Item is returned as array of fields. Each field is an object and I can only determine which fields I need by traversing each object and reading its field_id. Its returned like this:
item :[
{ ...
field_id: 3423423,
...
},
{
...
field_id: 343434,
...
}
...
]
I can rather send one request with an item_id and field_id and I'll get the field I need, but I'll have to make 7 of these calls. Which is better?
I recently had to make a similar decision and I ended up adding methods to the back-end that packaged the data up in a format that was more suitable for consumption. If you are able to do that, I would recommend that approach.
I suspect that the API is out of your control.In that case, I would probably go with multiple async calls so that you can provide feedback while the data is retrieved. Using async calls and promises you can let all the individual pieces get retrieved in the background in whatever order they come in and then assemble them from there.
New to backbone/marionette, but I believe that I understand how to use backbone when dealing with CRUD/REST; however, consider something like results from a search query. How should one model this? Of course the results likely relate to some model(s), but they are not meant to be tied to said model(s).
Part of me thinks that I should use a collection using a model that doesn't actually sync with a data store through the server, but instead just exists as a means of a modeling a search result object.
Another solution could be to have a collection with no models and just override parse.
I assume that the former is preferred, but again I have no experience with the framework. If there's an alternative/better solution than those listed above, please advise.
I prefer having one object which is responsible for both request and response parsing. It can parse the response to appropriate models and nothing more. I mean - if some of those parsed models are required somewhere in your page, there is something that keeps reference to this wrapper object and takes models from response it requires via wrapper methods.
Another option is to have Radio (https://github.com/marionettejs/backbone.radio) in this wrapper - you will not have to keep wrapper object in different places but call for data via Radio.
I'm developing a REST API based on the HAL specification. The API is being developed in PHP with Symfony and the client is being build in angularjs. The API must return some lists and they are going to be shown using ngtables library, and filtering options will be needed, ideally in the format that ngtables uses, like in this sample.
{ "name": "M", "age": "4" }
(Of course future clients may be use the same options.)
My frontend-workmate is suggesting me to send the json encoded directly as a parameter in the url, like this:
?filter=%7B%20%22name%22%3A%20%22M%22%2C%20%22age%22%3A%20%224%22%20%7D%20
I'm not very sure about that though.
I've been reading how to send arrays through the URL with a parameter like param[]=foo¶m[]=bar but that does implies have one key for multiple values. In my case I need to be able to send different key-values for the arrays like a Json object does.
I'm wondering how should be the Request URL from the client to be able to include all the filter options inside one parameteror and if there is any standard way to do that.
EDITED: After #Ross_Turner I want to clarify that my intention of passing a key-value array inside a parameter is because we'll have another type of parameter. For example:
?filter=<my key-value array>&page=1&limit=50&anotherParam=whatever
Even we would like to use another parameter containing another key-value array like this:
?filter=<my key-value array>&sorting=<another key-value array>&page=1&limit=50
Where filter and sorting can have the same keys.
Currently there is no standard way to send queries in GET requests. So you have 2 options: you use your custom query language (like you already tried) or you choose a standard query language. Either way it is hard to make it RESTful, because you have to create a link, which contains a recipe how to generate such an URI. You can probably use URI templates, but sometimes they are not general enough...
#Ross Turner:
I think you misunderstood, I was talking about not having a standard. Ofc. there are non standard query string based solutions, for example RQL. Or you can send a standard SPARQL query in a single param, but there is no standard way to describe such a link, and without link descriptions you cannot generate the query in a REST client, so it won't be loosely coupled and so it will violate the uniform interface constraint.
I disagree with #inf3ero's answer - surely there is a very well defined way to send a query as part of a GET request - query parameters. If you want different key and value combinations this is the principal of the keys and values of query parameters, so in your example you should probably use ?name=M&age=4 and parse each of these on your server. It should be simple enough to convert
{ "name": "M", "age": "4" }
into this by iterating over the keys in the JSON object. I'm not sure why you would want to combine these into a single parameter if you are attempting to implement a RESTful API following the HAL specification.
I'm trying to figure out how to get nested structs to work with GAE datastore using Go. I know the datastore doesn't specifically support nested structs. I need to find a simple way of getting user information to go with a post when it is sent out to a user as JSON.
One thing I thought of was to put two fields for the user. One for the ID/key referencing to user and another one for the user type struct which would be added there when the post is loaded from the datastore. Extra fields seem silly so I'm hoping there is a better solution for this.
There are two entity types or structs: POST and USER
Posts need to contain information about the user who made the post.
The structure for the JSON I'm going to output for users is as follows:
POST
field1
field2
USER
user_field1
user_Field2
Go's appengine datastore api provides the PropertyLoadSaver interface for this sort of thing: https://developers.google.com/appengine/docs/go/datastore/reference#PropertyLoadSaver
You structure your struct however you want and then implement the Load and Save methods of that interface to populate it correctly. It means you write the serialization code yourself but it gives you full freedom in how you structure your data.
This will allow you still filter over the fields and have a nested struct.
The python runtime has the ndb library which supports nested structures like this. Go does not, so I can think of two solutions:
In the POST kind, have a user field that is a key, referencing a USER kind with the necessary fields. Requires two fetches and roundtrips.
Make a user field in the POST kind that is a blob. The blob is a string that is [de]serialized in go. This means you can't search or filter on any of the user data, but it also allows you to store everything in one entity.
You should use these based on the needs of your app. If you need users to be a real thing, use 1. If users aren't objects you need to work with (i.e., just data to display), you can use 2.