I didn't want to ask such a basic question but I seem to not be able to find the answer on my own.
How can I query a specific plant without knowing its id?
Such as using the common name or binomial name.
I see that according to the documentation the path is /api/species/{id}, it might be my inexperience on using APIs but I'm left clueless on how to query a specific plant without prior knowledge of their id.
Would anyone be able to give me an explanation of how it works or even better link me to an article to fill the gaps of my API knowledge?
My current knowledge stems from the freecodecamp JSON APIs and AJAX short course which doesn't help when faced with this sort of documentation.
I got the response from another forum and then complemented it by learning more about REST APIs - APIs for Beginners - How to use an API (Full Course / Tutorial)
At the basic level in the form of a URL:
You start with the provided URL - https://trefle.io/api
Select which type of data you want such as Kingdom, subKingdom,
division, etc All the way down to plants or species. -
https://trefle.io/api/plants. As it is mentioned, "Plants
are all main species, without all the varieties, cultivars,
subspecies and forms", and species will give you all that belongs
to that species meaning several plants.
You provide the parameters that you want, with some being required and others being optional.
To know which parameters to use you can read underneath here, such as token, page_size, page, etc.
The first parameters
would go in front of the former link like so with ? -
https://trefle.io/api/plants?q=strawberry and the following parameters
are separated with a & like so -
https://trefle.io/api/plants?q=strawberry&token=yourAPIkey and
you can add any parameters to that such as showing only items with complete
data, minimum ph, or others that might interest you.
But do keep in mind that the database still seems to be particularly incomplete.
Also, this is in the form of a URL, in practice, this would be done differently, I recommend watching the video I linked above where he goes through a lot of this information and showcases helpful tools such as Postman.
Related
Why is it a bad idea to have a ID in the URL in terms of SEO? How does this URL
http://example.com/user/1234 hurt SEO?
Can someone give me a practical example where search engine rankings are worse?
The reason people are saying that {ID} in the URL is bad is due to the way search engine algorithms work. When a search term is located in the actual URL, it is weighted much more heavily than the content of the page, etc.
For example:
<!-- http://example.com/blog/57 -->
<html><head><title>An article on search engine optimization</title>...
vs
<!-- http://example.com/blog/an-article-on-search-engine-optimization -->
<html><head><title>An article on search engine optimization</title>...
If you do a search in Google for "Search Engine Optimization" the second page, the one with the slug in the url will weight as a better result than the one with only the id.
You can deal with this in the same way that stack overflow deals with this issue:
http://stackoverflow.com/questions/{id}/{slug}
http://stackoverflow.com/questions/910683/why-is-id-in-the-url-a-bad-idea
The combined id and slug format really helps you achieve the best of both worlds. You get the ease of programming by retrieving records by {id}, but you also retain the optimized search URL because of the {slug}.
It does have an effect of the click-through rate.
The url is presented in green below the search result - so if it contains relevant words the user might click your site and not another site.
Which would you rather click:
www.test.com/page.php?u=85583
OR
www.test.com/Solution-to-your-problem.php
As commented this effect may be achieved even with urls including an id.
In the olden days it search engines treated words in url with much respect and gave those pages extra credit and higher ranking. This effect has almost vanished. We are left with two other effects of readable urls:
Clickthrough
Linkbuilding: Easier for a human to copy such a url and after the link is copied it is often referred to with some of the slug words. The url with "Solution-to-your-problem" may have Solution to your problem inside the a tag also when people link to your page. This will influence your ranking.
A solution with id + slug might be the best solution and it fixes the problem of keeping track of slug changes.
test.com/85583/solution-to-your-problem
But there are some rules to follow, you should do a 301 redirect if the slug is incorrect to prevent a lot of duplicate content pages. Spam/duplicate content detecting kicks in if you got a lot of similiar pages:
test.com/85583/solution-to-your-problem
test.com/85583/solution-to-yar-problem
test.com/85583/evil-competitor-spamming-you-haha
Including the id also requires your ids to be as short as possible, an url with a full guid might be confusing to the eye and prevent a good clickthrough:
test.com/0CD03822-4A35-11DE-BF38-3F9356D89593/solution-to-yar-problem
Remember that Google News even demanded that you had an id in your url to be included.
Well, my name is Sudhir Jonathan, so if I want people to find me on your site, example.com/user/sudhir-jonathan is much much better than example.com/user/1234. Simply because the object of your page - "Sudhir Jonathan" - is now present in the url itself. This is a big win.
Similarly, example.com/articles/how-to-bake-a-cake is ranked much higher than example.com/articles/2379797 for the search term "bake a cake".
See this Do SEO-friendly URLs really affect a page’s ranking? question. Based on the answers, no-one can find any proof that IDs in the URLs has any effect on SEO.
It simple, search engines care words rather than number. That is to say, it will be better to see keywords in url than just ID sine ID/number is useless for search engines to determine whether your site is relevant or not!
It's always a bad idea to provide unusual information. Try the user name instead!
For SEO there is no real advantage/disadvantage between static ID urls and username urls.
1) you miss out on keywords in the url
2) it's harder for a human to read and understand what the link will be about
3) sql injection is a lot easier with IDs
I'm in the process of designing my first serious RESTful API, which will sit above a WCF service.
There are resources like; outlet, schedule and job. A schedule is always owned by an outlet, and a schedule will contain 0 or more jobs. A job does not have to be on a schedule.
I keep coming back to thinking that resources should be addressable in the same type of way resources are addressed on a file system. This would mean I'd have URI's like:
/outlets
/outlets/4/schedules
/outlets/4/schedules/1000/jobs
/outlets/4/schedules/1000/jobs/5123
Things start to get messy though when considering how to pull resources back under different situations though.
e.g. I want a job not on a schedule:
/outlets/4/jobs/85 (this now means we've got 2 ways to pull a job back that's on a schedule)
e.g. I want all schedules regardless of outlet:
/schedules or /outlets/ALL/schedules
There are also lots of other more complex requirements but I'm sure you get the gist.
File system's have a good, logical way of addressing resources. You can obviously create symbolic links and achieve something approximating what I describe but it'd be messy. It'll be even messier once things get even slightly more complex, such as adding the ability to get schedules by date:
/outlets/4/2016-08-29/schedules
And without using query string parameters I'm not even sure how I'd request back all jobs that are NOT on a schedule. The following feels wrong because unscheduled is not a resource:
/outlets/4/unscheduled/jobs
So, I'm coming to think that file system type addressing is only going to work for the simplest of services (our underlying system has hundreds of entity types, with some very complex relationships and a huge number of operations).
Having multiple ways of doing the same thing tends to lead to confusion and messy documentation and I want to avoid it. As a result I'm almost forced to opt for going with the lowest common denominator and choosing very simple address forms - like the 3rd one below:
/outlets/4/schedules/1000/jobs/5123
/outlets/4/jobs/5123
/jobs/5123
From these very simple address forms I would then need to expand using query string parameters to do anything more complex, e.g:
/jobs?scheduleId=1000
/jobs?outletId=4
/jobs?outletId=4&fromDate=2016-01-01&toDate=2016-01-31
This feels like it's going against the REST model though and query string parameters like this aren't predictable, so far from the "no docs needed" idea.
OK, so at the minute I'm almost on the side of the fence that is saying in order to get a clean, maintainable API I'm going to have to go with very simple resource addresses, use query string parameters extensively and have good documentation.
Anyway, this doesn't feel like the conclusion I should have arrived at. Where have I gone wrong?
Welcome to the world of REST API programming. These are the hard problems which we all face when trying to apply general principles to specific situations. There is no clear and easy answer to your questions, but here are a few additional tips that may be useful.
First, you're right that the file-system approach to addressing breaks down when you have complex relationships. You'll only want to establish that sort of addressing when there's a true hierarchy there.
For example, if all jobs were part of a single schedule, then it would make sense to look to schedules/{id}/jobs/{id} to get to a given job. If you think of it from a data-storage perspective, you could imagine there being an XML file for each schedule, and the jobs would just be elements within that file.
However, it sounds like in this particular case your data is more relational. From a data-storage perspective, you'd represent each job as a row in a database table, and establish some foreign key relationships to tie some jobs to some schedules. Your addressing scheme should reflect this by making /jobs a top-level endpoint, and using optional query string parameters to filter by schedule or outlet when it makes sense to do so.
So you're on the right track. One more thing you might want to consider is OData, which extends the basic REST principles with a standards-oriented way of representing things like filtering with query string parameters. The address syntax feels a little "out there", but it does a pretty good job of handling the situations where straight REST starts falling apart. And because it's more standardized, there are tools available to help with things like translating from a data layer into an OData endpoint, or generating client-side proxy helpers based on the metadata exposed by that endpoint.
This feels like it's going against the REST model though and query string parameters like this aren't predictable, so far from the "no docs needed" idea.
If you use OData, then its spec combines with the metadata produced by your tooling to become your documentation. For example, your metadata says that a job has a date property which represents a date. Then the OData spec provides a way to represent filter queries for a date value. From this information, consumers can reliably produce a filter query that will "just work" because you're using a framework server-side to do the hard parts. And if they don't feel like memorizing how OData URLs work, they can generate a client proxy in the language of their choice so they can generate the appropriate URL via their favorite syntax.
I’m trying to show a list of lunch venues around the office with their today’s menus. But the problem is the websites that offer the lunch menus, don’t always offer the same kind of content.
For instance, some of the websites offer a nice JSON output. Look at this one, it offers the English/Finnish course names separately and everything I need is available. There are couple of others like this.
But others, don’t always have a nice output. Like this one. The content is laid out in plain HTML and English and Finnish food names are not exactly ordered. Also food properties like (L, VL, VS, G, etc) are just normal text like the food name.
What, in your opinion, is the best way to scrape all these available data in different formats and turn them into usable data? I tried to make a scraper with Node.js (& phantomjs, etc) but it only works with one website, and it’s not that accurate in case of the food names.
Thanks in advance.
You may use something like kimonolabs.com, they are much easier to use and they give you APIs to update your side.
Remember that they are best for tabular data contents.
There my be simple algorithmic solutions to the problem, If there is a list of all available food names this can be really helpful, you find the occurrence of a food name inside a document (for today).
If there is not any food list, You may use TF/IDF. TF/IDF allows to calculate the score of a word inside a document among the current document and also other documents. But this solution needs enough data to work.
I think the best solution is some thing like this:
Creating a list of all available websites that should be scrapped.
Writing driver classes for each website data.
Each driver has the duty of creating the general domain entity from its standard document.
If you can use PHP, Simple HTML Dom Parser along with Guzzle would be a great choice. These two will provide a jQuery like path finder and a nice wrapper arround HTTP.
You are touching really difficult problem. Unfortunately there are no easy solutions.
Actually there are two different parts to solve:
data scraping from different sources
data integration
Let's start with first problem - data scraping from different sources. In my projects I usually process data in several steps. I have dedicated scrapers for all specific sites I want, and process them in the following order:
fetch raw page (unstructured data)
extract data from page (unstructured data)
extract, convert and map data into page-specific model (fully structured data)
map data from fully structured model to common/normalized model
Steps 1-2 are scraping oriented and steps 3-4 are strictly data-extraction / data-integration oriented.
While you can easily implement steps 1-2 relatively easy using your own webscrapers or by utilizing existing web services - data integration is the most difficult part in your case. You will probably require some machine-learning techniques (shallow, domain specific Natural Language Processing) along with custom heuristics.
In case of such a messy input like this one I would process lines separately and use some dictionary to get rid Finnish/English words and analyse what has left. But in this case it will never be 100% accurate due to possibility of human-input errors.
I am also worried that you stack is not very well suited to do such tasks. For such processing I am utilizing Java/Groovy along with integration frameworks (Mule ESB / Spring Integration) in order to coordinate data processing.
In summary: it is really difficult and complex problem. I would rather assume less input data coverage than aiming to be 100% accurate (unless it is really worth it).
Im working with the google-mapquest mapping API. I need to add some Points of Interest near a certain area from a given latitude-longitude location.
I search the google and mapquest documentation to figure out if there is a method to get all zip-codes in that area but i didnt find anything that does that.
I tried the harvesine implementation to calculate the nearest point given in that radiuos/latitude-longitude and it works fine. The problem with this approach is that i need to update constatntly the database, so i dont like it much.
The question is: Is there a service (google-mapquest or another) that gives you this information?.
No, there is no API for either service that I am aware of. Your best bet is to just get a ZIP Code database and use that. Some really good inexpensive ones are out there. I prefer http://www.zip-codes.com/zip-code-database.asp. Their $40 package is very accurate, updated monthly, and licensed by the USPS (so you know it's quality data).
UPDATE:
I found a WebService that does exactly what i need. You could provide only a simple ZipCode and a country or perhaps a full address and in the response you get the longitude/latitude. Then i send the Latitude and Longitude returned to get a list of all the ZipCodes near the provided coordinates and a given Radius that also can be customized.
You can filter the total rows you want the service to return, or even if you are gonna use miles or kilometers as the measure unit.
So, basically with the returned information, i feed those coordinates for each of the nearest ZipCodes obtained to the google API and render those points of interest into the map that you need to show.
The services are provided by GeoNames. Its an organization dedicated to Geolocalization services. They offer also premium data, but in particular these services are free of use, obviously the information is not as accurate as the premium one, but actually in my tests i found that that is trustful and the response also is very fast.
Another good advantage is that the process to get a Key for use Geonames services it's quite simple.
I left you the link of the services that i'm talking about.
List of available services:
http://www.geonames.org/export/web-services.html
Hope it helps many people.
Regards!
Users will be able to write some documents. Those documents will consists of chapters (one-to-many relation).
Normally I would do this by creating separate views for creating chapter and document.
How to implement web page that allow to edit "composite" view? Where I can edit document details, but also create chapters, without visiting different pages? Also how can I ensure that I pass order of chapter user have arranged (by moving chapters freely up and down)?
(Sorry if that question already have be asked&answered but I do not even know how to search for it :| since I do not know proper keywords beyond "AJAX", so help in naming my requirement would also be welcomed!)
Backend servers applications based on REST principles work nicely with Ajax client-side implementations.
For example, your URLs could be:
/book/1
/book/1/chapters
/book/1/chapter/1
You could set it up so that a POST to /book/1/chapters would add a chapter. A GET on that same URL would return all chapters. A GET on /book/1/chapter/1/ would only return chapter 1. A PUT on /book/1/chapter/1/ would update an existing chapter. This is a "RESTful" architecture:
http://en.wikipedia.org/wiki/Representational_state_transfer
This is an interesting introduction: http://tomayko.com/writings/rest-to-my-wife
This is a big subject, but if you create the right backend server architecture you will find your job a lot easier. Hope this helps answer your question.
Ok Partial solution.
Just google Nested Forms Ruby on Rails. Plenty of examples, all in ajax, all easy.