API: Subject Queries

Loading...

Del curso dictado por Johns Hopkins University

Capstone: Photo Tourist Web Application

18 calificaciones

Johns Hopkins University

Capstone: Photo Tourist Web Application

18 calificaciones

Curso 6 de 6 en SpecializationRuby on Rails Web Development

In this Capstone project for the Photo Tourist you will implement a Ruby on Rails web application that makes use of both a relational and NoSQL database for the backend and expose the data through services to the Internet using Web services and a responsive user interface operating in a browser from a desktop and mobile device. You will have a chance to revisit and apply what you have learned in our previous courses to build and deploy a fully functional web application to the cloud accessible to your co-workers, future employers, friends, and family. In developing the Photo Tourist web application, you will get to work with different data types and data access scenarios (e.g., fielded data display and update, image upload/download, text search, access controlled information) to provide your users the ability to show off their photos and information from trips they have taken and to seek out photos and information from trips taken by others. Using the application you develop, your users will be able to • Create an account • Upload and download photos to the site and make them accessible to others • Provide descriptions of trips and photos that others can read • Organize photos by location and trip, • Find photos based on location • Find photos based on text searches of descriptions • Locate the place where the photo was taken on a map

De la lección

Geolocation

In this module you will add geolocation capabilities to the end-to-end application. This will allow your users to assign a geolocation position to images as well as identify the current origin and distance limits for future API queries. You will implement the model and API queries for subjects within this module and complete the UI components within the next module. At the data tier you will add geolocation coordinates to the Image model, make those geolocation coordinates available to ThingImage though the 1:1 relationship between them, implement geolocation queries using the Geokit Rails gem that determine all items within a distance limit from an origin and supply their distance from origin. These queries will leverage custom SQL selects, joins (inner, right outer, and left outer join) and will be encapsulated within ActiveModel query scopes. At the API tier you will implement API service endpoints to geocode addresses and reverse geocode positions into a resolved location using the Geokit Rails gem and the Google Maps Geocode service, implement a persistence cache of geocode results using MongoDB to help stay within free service limits and speed up lookups, enable an API service endpoint to query for subjects (ThingImages) of a certain type, within a distance limit, and dynamically annotate them with the distance from the supplied origin, implement HTTP caching headers for both geocode and subject results. At the UI tier you will implement a geocoder service to lookup a location by (partial) address or position from the API implemented on the Rails server, add geocoding to the Image editor to allow a user to specify the Image's position using an address, build a current origin component to express and retain the center origin and distance limits for future subject queries.

Server: Geocoding and Setup10:38

API: Geocode API8:02

Server: Geocode Cache14:30

API: Image Position5:37

API: Subject Queries13:28

API: Subject Query Results Caching13:33

Conoce a los instructores

Jim Stafford
Adjunct Professor, Graduate Computer Science
Computer Science, Whiting School of Engineering

[MUSIC]

In this lecture we will discuss adding subject queries to our API.

We're going to be looking for thing images within a range and

we're going to want to constrain them by type,

like thing images that represent the primary image for Things.

And then we'll provide some finishing options where each instance will tell us

how far that instance is from the provided origin.

And the ability to order the results either in ascending or descending order.

So in the last lecture we started our geolocation API focus on our business

objects focusing on Image.

And next we're going to focus on ThingImage and

integrate all the query scopes that we put together in the previous lesson.

Now we get to the UI portion of this module, the geocode and

the Image position will be specifically used.

But we won't be using the search in total until the next module, where we'll

be developing a page and a several views that will leverage the search and

display of subjects or ThingImages.

This is all in preparation.

So the test that we are creating, cleans the database prior to and

after all tests have been run.

And then before each test runs, we go and

look to see, have we populated the database yet?

And if not, we're going to populate the database.

With 10 things, and each thing will be given 2 images.

And we don't need content, so let's just set content to nil.

Make it run a lot faster.

One of those images will be priority zero and

the other one will be priority one based upon the index.

And then we'll build a random origin.

Then we want to calculate the average distance, all things are from that origin.

And when we calculate things,

we are trying to reduce the images to only priority zero.

So we start out with a query scope of Image.things.

And then we do a database query that says now find me the distance relative

to this origin for each of those ThingImages, and

annotate each of the instances returned with the value they are from that origin.

And then using a map, we will return an array of distances.

And then prior to finishing out, we want to come up with the average of those

distances, where we'll use the reduce to sum up all the elements of the array,

and divide by the number of elements in that array.

Now what you're seeing for reduce here is just a shorthand for starting with 0,

let's apply the following operator to each element in

the array starting with this value and return the resulting value.

So we can demonstrate that through Rails console.

We pass in a 0 that, but if we start at 1 we'll get 4.

Okay, and reduce is just sort of like an alias for inject.

They pretty much mean the same thing.

And then, if we want to get a little more verbose, we could express it this way and

have our block called.

Or we can just say reduce, okay?

So as I said we're going to go back to our query scopes and

start to integrate those in with the API.

And the first thing we're going to be testing is searching our subjects which

are our ThingImages for any that are within a distance of miles and

it had in an expression of the origin.

And since it's early, Let's go ahead and

print what we are passing to and getting return from our API.

So we see we're going to pass miles longitude and latitude but

currently, there's no URI defined, or at least no helper method for our subject.

Let's go fix that.

Let's go into config/routes and add a get for subjects and

route that over to the thing_images controller #subjects.

And then if we use rake routes, in order to check our results,

we'll see that we now have a subjects helper method.

We have a URI under /api/subjects.

And that's being routed over to the controller that we expect.

So obviously, if we're going to define the fact that our thing_images controller

has a action method for subjects, we have to define that method.

And before we go too far with this method I know I

probably ought to go into the policy and say, yeah, cverybody can call it.

Because that is going to be our policy.

But I'm going to go ahead and take a shortcut and go ahead and

exclude it from the policy within the controller.

And I'll do that in the name of just showing you an example of

how to do that, okay?

So our subjects action method does not have to call verify_authorized.

But one of the things it does have to go on is our subjects action

requires an origin.

And so let's make it easy on our implementation and

have a before_action that'll resolve that origin for the subject.

So at the bottom of the controller, let's go ahead and

add a helper method called origin.

And what it's going to do is inspect the parameters and

pluck out what it believes is an origin.

And so if it sees longitude and latitude it's going to say that looks good.

I'm going to go ahead and now create a new Point based upon the float values

of the longitude and latitude being passed in.

And there might have been another couple of cases of how we could pull out origin,

like if you were saying relative to an image, or relative to a thing.

But let's stop right now and say well if that wasn't enough,

let's go ahead and raise the fact that we have a missing parameter.

And tell them that lat and long, or

an address, is going to be required in order to call this method.

Remember, we're going to to be able to geocode by address as well as

lat and long.

So we've already taken care of origin.

And the other parameter that we're passing in is miles.

So let's go ahead and let our action method take care of extracting that.

And then what we want to do is do a range query, where we'll look for

all thing_images within miles of the origin.

And when we return it, we want to include both the thing name,

the caption for the image, as well as the image position.

Now we have no subjects view,

which would be the default if we just returned right here.

So what we want to do is signal that we want

the thing_images/index marshaler to be used when returning a result.

When we look back at our test results, we're looking pretty good, except for

something that we should be very familiar with.

We need to add position to the ThingImage marshaling.

So over in the view for thing_images, in its index,

here's our current implementation of how we're marshaling a thing image.

So the representation of ThingImage at this point is based upon a query scope

which only put a flat longitude and latitude in with the object.

We don't have a position represented as a point that we can just call to hash on.

Let's just play it easy and

manually marshal it out here since it's a very simple object.

Note that not all of the thing_images that marshal will have a longitude and

a latitude.

Note, we are using the generic index view, so

we need to test whether this thing_image responds to longitude.

We could have also test for latitude, but I think one's enough.

And then it does a double check to see, well does it even have a longitude value?

Just trying to cut down on marshaling nils, okay?

So with the view properly in place, our test is now passing.

That we passed in a criteria that said we wanted things within 33.3

miles of this origin, and we get a list of things back telling us their position.

This is within 33.3 miles.

We'll add distance later, but for right now we're just looking for

things within a particular set of miles without telling us how far they are, okay?

So when we look at the next test,

we'll find that we're not finding specifically things.

On the previous test, we just said find anything within range of a position.

The test we're focusing on now says,

I was only expecting to get 4 ThingImages back, but I got 11.

Okay, in the previous test, when we issued it, we issued it a bit unconstrained.

Although, we didn't put any orphan images in there to prove that out.

What we're going to do in this next case is latch it down to only Things come back.

So we're in the controller.

What we'll do is we'll inspect the parameters to see whether the caller

provided a subject.

And if they did supply a subject, we would apply this additional query scope

of .things if that subject was supplied and

if we were to normalize it and it were to result in the word "thing", okay?

And now with that implementation in place we're finding the correct

number of things.

We're also finding that our test to find images is also working, but

you realize that the rules for images and things are different.

I only want to find things that have a priority zero image,

whereas image, I just want to find images.

And so with find images, I go off and

I create several images that don't have a thing.

I use a helper method.

And then I go off and do a query and say,

tell me everything within 100 miles of this origin.

And we can ignore distance for right now.

And so what I expect in the payload that I get back are,

in addition to things, are all the images that I put in without things.

All right, next I want to get into some results finishing, meaning,

we're going to add some touches to our overall results.

You're going to get the same number of elements back, but it's going to have

more information, or they're going to be ordered in a particular different way.

So my first two tests verify whether we do, or don't,

provide distance in what get's marshaled back.

And in this simple bag of results, it issues a query, like we've been seeing,

and it just verifies that each element coming back doesn't tell us the distance.

And the one that's failing is one that actually asks for distance, and

then checks that each ThingImage returned has a distance element and

it is of a floating point class.

So to test for an additional argument,

what we'll do is we'll look in the params for a distance element.

And if it does not exist we will set it to the word "false".

And then if the lowercase value of what's in distance at this point in

time equals the value of "true", we will use our helper method within ThingImage

to take our query scope, iterate through it, and augment the objects within

that collection with a distance value from the origin that we are supplying.

But of course, this is where our tests keep us honest and say, even though

we were including distance in the object, it wasn't getting marshaled in our view.

And we'll go over to the view for

the thing_images/index.json.jbuilder and add a marshaling of distance.

If the object responds to distance, the distance is not nil, or

the distance is not a negative number.

If you remember back that one query scope I had,

is the default SQL query would assign a negative one to the distance, and

then depend on follow-on processing to actually put a value in there.

And this just makes sure that we don't marshal any of those fields out that

wasn't touched by that calculation.

Okay, with those changes in place, we are now properly annotating our

thing_images that get returned with a distance value, distance from origin,

and our test is now passing.

Now we'd like to do is add some ordering to our results.

And in the spec, we'll take advantage of a shared example called ordered, and

then request it either to be ascending or descending.

I'm assuming I don't have to step through the actual details of the validation.

But what's most important is how we express the fact we want our ordering.

And what we're going to do is pass another parameter of order and

supply a direction, ascending or descending.

And so if we come back into our controller, into our subjects action, and

we'll define a reverse parameter which will be true if order is supplied and

order downcased will equal "desc".

Otherwise reverse is going to be false.

And then we need to take that value and pass it to within_range.

So we're going to default our result in coming in ascending order but

allow things to be in descending order.

And so now all our tests for results finishing are passing.

We're able to return a collection without distance so

we don't have to calculate it all the time.

We can return a collection with distance so that our users know that not only

this thing is within a particular range, but this is how far it is from the origin.

And they can have it in a ascending order or a descending order, okay?

In summary, we added subject queries to our APIs.

Now we're able to find thing images within a particular range and

able to constrain it to either all images or things with a primary image.

We added on some finishing options, like annotating each object returned with

the distance from the origin provided, as well as the ability to order the results,

either in ascending or descending order.

Whats next?

Subject query results caching.

Let's finish up our API by supplying some cache headers in order to

coordinate client updates.

Explora nuestro catálogo

Inscríbete de manera gratuita y obtén recomendaciones personalizadas, actualizaciones y ofertas.

Coursera brinda acceso universal a la mejor educación del mundo, al asociarse con las mejores universidades y organizaciones, para ofrecer cursos en línea.

© 2018 Coursera Inc. Todos los derechos reservados.

Descargar en la App Store

Consíguelo en Google Play