I could find Airport and a property amenityFeature in Schema.org. I need to find a way to represent a Lounge that belongs to an Airline.
How to find a Lounge that belongs to Airline on an Airport?
You can represent the lounge with LocalBusiness.
You can use the containedInPlace property to state that this LocalBusiness is part of the Airport.
You can use department/parentOrganization/subOrganization to state that the LocalBusiness belongs to the Airline.
Related
I am building a web application where I need to store a large number of unique addresses as nodes in ArangoDB.
One approach would be using a hierarchical graph model: a country node connected to county nodes, county nodes connected to cities and cities connected to exact addresses with GeoJSON attributes.
The other option would be having only address nodes which contain city, county and country as attributes.
Which method would be more beneficial? I would be running queries to find locations in a given range or locations in a given city.
Well, let's see what you will need in terms of collections to build your app:
Collection storing the Places you want to use in your app. This would be your main collection and would contain among other things a map location object {longitude: XXX, Latitude YYY}
Because you probably want people to be able to search by city, country, etc.. You need either a collection per Location type (city, country, etc) or a table with all the locations and a "type" flag that indicates the location is city or country, etc....
3.- You need a table that allows you to start at a country and drill down to a particular set of cities (for example). So, you need a table with a from key and a to key
By this point you probably have noticed that we have basically built a hierarchy, which in Arango I would build as at least one Places vertex collection, a Locations vertex collection and a locationContains edge collection. This would allow for really fast lookups and is one of the reasons why graph databases were originally created.
Now note that since Arango is a multi model DB, you can use the graph syntax (I like anonymous graph syntax myself), but you can also use traditional joins whenever needed, which behave very similar to a traditional relational DB.
I have a website providing a ranking (based on reviews) of other websites that require a membership to access them (ex. Online tool requiring a monthly membership).
I have 2 question related to this:
Should I use the Product or WebSite entity? At the moment I opted for Product since it has the price attribute and so on.
How can I describe my ranking of website? I'm looking for a kind of ordered list of products (or websites if I have to change that).
With the offers property, you can directly offer the WebSite (or WebApplication, which might be more appropriate in your case). No need for Product.
For the ranking, you have several options:
With the review property you can specify a Review, which can have the reviewRating property to specify a Rating. This allows you to provide specific scores (e.g., in the form of "1.27", "1.28", "2.04" …).
If the rank is the average rating from all reviews, you can use the aggregateRating property to specify an AggregateRating.
With an ItemList you could specify for each entry a ListItem with the position property. This allows you to (implicitly) provide a ranking (i.e., in the form of "1", "2", "3", …).
You could also use both ways (Rating/AggregateRating and ItemList).
Make sure to apply the review/aggregateRating on the correct item: on the Offer if you are ranking the offers, on the WebApplication if you are ranking the apps.
I'm designing a REST-API and currently I'm stuck with the following question. For example I got the following structure:
/foods/fruits/{fruit}
/foods/meat/{meat}
for example:
/foods/fruits/apple
/foods/fruits/pineapple
/foods/meat/chicken
Each of the endpoints is unique (only one apple, one chicken), but different sorts of fruits can exist (e.g. pineapple).
However my service needs to return either
one specific fruit (apple),
all fruits (collection-resource filled with all accessible fruits --> apple, pineapple)
or the whole food (composition of the collection-resources of fruits and meat)
With this design my resource is addressable about 3 URIs (composition, collection, endpoint), but it should be a maxima of 2.
It this a restful design?
Looking at the Richardson Maturity Model, you could have a generic Food resource and endpoint, with properties like type and name, and then your requirements would be accessible like so:
GET /api/food?name=apple
GET /api/food?type=fruit
GET /api/food
With this design my ressource is addressable about 3 URIs (composition, collection, endpoint), but it should be a maxima of 2. It this a restful design?
Could you provide a reference for the guideline that it should be a maxima of 2?
But either way - those three URIs are not 3 different URIs for the same resource, they are three different resources:
the food resource
a collection of foods of a particular type
a particular type of food
While the earlier resources can be considered to be composed of the others, it does not mean that the finest grain (the particular type, e.g. apple) is addressable via 3 URIs.
If you are using a hypermedia format such as HAL your composition representation could utilised embedded resources, which clearly illustrates that the contained resources are also available directly via their own endpoint.
Let's say that the domain structure of anapplication is as follows:
There is domain object called Department.
There is a domain object called Student.
There is a domain object called Paper.
The relationship between Student and Department is many-to-many.
A student can publish (create) a Paper for himself or for a
particular Department.
A student can view all the papers published by him for
himself and for departments to which he belongs (the latter includes
papers published by other students belonging to the same department
as the given student)
Here is what I think the restful uri designs should be like
Student creates (POST) a white paper for himself :
/students/{studentid}/papers
Student creates (POST) a white
paper for a particular department
/students/{studentid}/departments/{departmentid}/papers
Get all student papers published by him for himself
/students/{studentid}/papers/self
Get all student papers published by him for himself including the papers
of the departments to which he belongs
/students/{studentid}/papers
Similar get requests for point number 1 and 2.
The other way to arrive at the above end points would be something like (considering only points 1 and 2) :
/students/{studentid}/papers
and then pass departmentid in the request body. The application would the check for the presence of departmentId in the request. If it's not null then it will assume that this paper is being published for the given departmentid, otherwise for the student himself.
Which one of the above would be a better approach?
This link could help you to design your RESTful service: https://templth.wordpress.com/2014/12/15/designing-a-web-api/.
In addition, here are my comments regarding your URLs:
Everything that identifies your resource should be within the resource path (for example departmentid)
Regarding relations, we need to identify which URLs will handle references. For example, /students/{studentid}/departments/{departmentid}/papers will allow to attach an existing paper to a department or create a new one and in addition attach it to the department
I don't understand this url: /students/{studentid}/papers/self especially the token self. Does self refer to the current authenticated user? If so, I think that should use a query parameter since it doesn't really correspond to a resource... In fact, you rather use query parameters for list filtering
Hope it helps you,
Thierry
Since departmentid is part of how a resources is identified, it must be part of the URL. Putting it into the request body is a violation of REST principles.
When resource has a unique identifier it is retrieved:
/building/{building_id}
But what if "event" resource is described using building_id and floor_id parameters. How to name RESTful endpoint that is meant to retrieve present events?
To be precise, "event" resource has a unique identifier (id). Combination of building_id, floor_id ought to return present event in a particular location.
But what if "event" resource is described using building_id and floor_id parameters.
Is it? I recommend this:
If
GET /events/{id}
returns one event and
GET /events
returns all events, then
GET /events?building_id={building_id}&floor_id={floor_id}
returns the list of (possibly only one) event(s) at the combination of building_id and floor_id.
This looks like the often used filter-or-search-a-collection-resource-pattern.
Apart from the solution by Lutz, in case if you dont want them to be query parameters.
Assuming, from the name as it looks, floor_id is part of building_id , so if the event resource is defined as combination of both , it can be like
/event/{event_id}/building/{building_id}/floor/{floor_Id}
I'd start by trying to think what resource owns what. Obviously, buildings own floors (knock the building down, the floor is destroyed!) so that's a relationship that maps nicely to a sub-resource, but do events own buildings or do buildings/floors own events? No? Then we relate these by links. (A floor might have a current event concept as something it owns, but that's really a link to an event, not an event per se.)
/building/{building_id}
/building/{building_id}/floor/{floor_id}
/building/{building_id}/floor/{floor_id}/current-event --redirect--> some event
/event/{event_id}
The event probably should have hyperlinks to the building and floor which it involves. Going the other way, if there's no current event for a floor, fetching the …/current-event will result in a 404, and if there is an event, a 303 redirect will say which it is. (You might also want to make the record for the floor itself contain a true link to the event, as well as a convenience lookup sub-resource.)
A good RESTful application looks an awful lot like a densely linked website. Use the power of links and redirects!