Is there any official or unofficial documentation of twitter api which includes json schemas? For example the following link contains only sample response
https://dev.twitter.com/rest/reference/get/lists/members
https://dev.twitter.com/overview/api/tweets
Field Guide
Consumers of Tweets should tolerate the addition of new
fields and variance in ordering of fields with ease. Not all fields
appear in all contexts. It is generally safe to consider a nulled
field, an empty set, and the absence of a field as the same thing.
Please note that Tweets found in Search results vary somewhat in
structure from this document.
Related
I want to know, if the Json files that would be used in Elasticsearch should have a predefined structure. Or can any Json document can be uploaded?
I've seen some Json documents that before each record there's such:
{"index":{"_index":"plos","_type":"article","_id":0}}
{"id":"10.1371/journal.pone.0007737","title":"Phospholipase C-β4 Is Essential for the Progression of the Normal Sleep Sequence and Ultradian Body Temperature Rhythms in Mice"}
Theoretically you can upload any JSON document. However, be mindful that Elasticsearch can create/change the index mapping based on your create/update actions. So if you send a JSON that includes a previously unknown field? Congratulations, your index mapping now contains a new field! In this same way the data type of a field might also be affected by introducing a document with data of a different type. So, my advice is be very careful in constructing your requests to avoid surprises.
Fyi, the syntax you posted looks like a bulk request (https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html). Those do have some demands on the syntax to clarify what you want to do to which documents. "Index" call sending one document is very unrestricted though.
I am talking to an API that uses RAML. I am both downloading and uploading data to it.
When uploading data I had previously downloaded, I got a JSON Schema violation error, saying some of the parameters in the JSON objects were not allowed.
I realize the data i received is not following the JSON schema.
Is this kind of behavior a violation against the RAML principles?
What columns you GET and what columns you are allowed to POST may not be the same. For example, if you GET a user, it might include a user_id column, but you usually won't be allowed to write to it!
It's difficult to give a fuller answer without seeing the RAML spec document.
It's totally possible and valid to define different schemas for each HTTP method.
Is there somebody who knows how to use the Wikipedia API to get JSON or XML data out from a table on a specific Wikipedia page?
Is there maybe a different way to do this?
For example from here https://en.wikipedia.org/wiki/List_of_action_films_of_the_2010s
You can use curl (or use any other method/tool) to retrieve and/or parse a Wikipedia-URL via the public API. Here are two examples that should help you:
Retrieval of List_of_action_films_of_the_2010s:
JSON unparsed via the query action
JSON parsed via the parse action
Next, you would need to parse for and/or select the sub-elements relevant for your analysis. In this case I would assume: wikitable elements.
For reference and a detailed explanation, you can have a look at the general API page of MediaWiki and at the list of parameters on how to use the API to parse Wikipedia pages for certain data elements.
When I make GET HTTP call to Google Places API. (Example Call: "https://maps.googleapis.com/maps/api/place/nearbysearch/json?location=-33.8670522,151.1957362&radius=500&types=food&name=harbour&sensor=false&key=") ....
Under "results", inconsistent number of elements are returned. What is the base list of fields that will always be returned?
In the screenshot below, you can see how the array length count under "results" is different, counts are 11, 10, 10, and 8.
Screenshot below shows how one the JSON Arrays in the response has more elements than the other and the extra fields are circled in red.
I am confused here because I am trying to write code to parse the JSON and trying to understand which are the fields to expect? Missing fields in some arrays in the response is breaking my code.
Am I interpreting the API documentation incorrectly or Is this a bug that I should be filing with Google directly?
You might consider using logic that does not require any fields at all. Because the server is out of your control, it could return anything at any time (due to API changes, bugs, technical faults, etc.)
For example, in Sprockets I loop through whatever objects are returned and if the name matches something that I expect, then I process it. Otherwise the fields in my objects simply remain empty. You can see the top-level processing Java code in the PlacesResponse constructor.
It's not a bug, but documented behaviour. The Google Places API documentation says:
Each result within the results array may contain the following fields:
In other words, Google returns ratings, opening hours etc for places if it has them, but it will leave them out if it does not or the field is not relevant to the place (eg. you wouldn't have opening hours for an apartment complex or rate a train station). As #pushbit says, you have to parse accordingly and check whether each field was returned.
So I have a theoretical question based on a lot of research that I have done recently with regards to REST API interfaces.
Firstly I understand that in REST, resources should be nouns and not verbs and each resource should be decoupled from the next resource, however the resources can return the same entities or collection of entities, depending on the purpose of the resource.
My focus however is performing restful search.
In all the research I have done, the most common solution I have come across is the use of parameters in the URL
api.test.com/search-cars?param1=val1¶m2=val2
Now while this is standard practice and is not truly breaking the rules of REST, why is it that no one represents the search parameters as an id (possibly in the form of JSON)
api.test.com/cars/{"color":"blue","year":"2013","make":"toyota"}
If I look at cars as a resource and represent my id as a JSON, I could easily say that I truly have a finite number of cars thus a finite and unique number of id's.
Further more this promotes pure rest by conforming to "resource/id"
What are the benefits and downsides to using parameters as in the first example?
What are the benefits and downsides to using JSON as an id with the "filters" as in the second example?
All your comments would be really helpful as I need to take a final decision on how to move forward with the first resource of my API. Also, I need to have a strong argument for my boss explaining why I decided on either of the methods.
The general form of an URL is
scheme://domain:port/path?query_string#fragment_id
So you propose two URLs:
search by query_string
search by last path segment
Search by query_string
I recommend to name the collection cars, not search-cars. As you write in your question, URLs identify resources. The cars resource identifies the collection of all cars. I have no idea what collection a resource called search-cars would identify.
GET http://api.test.com/cars
would return the collection of all cars.
GET http://api.test.com/cars/123
would return the car identified by 123.
GET http://api.test.com/cars?color=blue&year=2013
would return the collection of all blue cars build in 2013.
Search by path
Your second URL
GET http://api.test.com/cars/{"color":"blue","year":"2013","make":"toyota"}
would make the query (JSON) a part of the path. To make the two examples equal, I suppose to make the JSON a query parameter:
GET http://api.test.com/cars?search={"color":"blue","year":"2013","make":"toyota"}
JSON vs. named query parameters
Most REST frameworks support mapping of query params to method parameters.
Most REST frameworks allow you to map a path segment to a method parameter. And, again, most REST frameworks allow you to map JSON to an object or a simple dictionary.
What makes JSON harder to use is the need to escape the "{} characters:
{"color":"blue","year":"2013","make":"toyota"}
becomes
%7B%22color%22%3A%22blue%22%2C%22year%22%3A%222013%22%2C%22make%22%3A%22toyota%22%7D
which is not very nice.
Summary
You can use both the query_string and the path of the URL to identify a resource. Search parameters are better placed in the query_string because the ? can mentally be translated to the WHERE of SQL.
Don't use JSON in URLs because escaped JSON is hard to read.