I am trying to make a blog in Directus.
I created Blog Collection and Categories Collection.
I am using junction table with many to many relationship to connect categories to blog.
I can create a new blog post and select category from category collection and I can add a new category also.
But when I am calling in api, it is not showing the category field in my rest api call.
I can call category endpoint and view the list of all the categories in rest api but in blog collection endpoint, I cant view related category name.
I want to view all the selected category name to each blog posts in my rest api.
And I want to view all the blog posts when I call category collection in my rest api by putting category name like projectname/items/categories/aliens/ so I can see all the blog posts of aliens categories.
Currently I am getting this by calling my blog collection in json -
{
"data": [
{
"id": 1,
"status": "published",
"owner": 1,
"created_on": "2020-03-16 21:15:25",
"blog_title": "first blog post title",
"blog_content": "<p>sdlkjfhsdkfol8ysdmfhj sd,fh klsdhf msoiudf oihsdyfghm soreht4,7shetc,oiuh,scenclkr</p>\n<p><strong>dsfgdsfgds</strong></p>"
}
]
}
How to get the category name on rest api ?
Did you try using the fields parameter? This is used to fetch deeply nested relational data:
?fields=*.*.*
In this example, the asterisk is a wildcard for_all_ fields at that relational depth... so this fetches three levels deep.
https://docs.directus.io/api/query/fields.html
You should have a relational table created between those 2 tables so you should be able to filter the information like this ?fields=id,blog_title,blog_content,category.category_id.category_name,category.category_id.status
In case this is confusing let me try to simplify the relationship part:
category.category_id.category_name
<field_name_on_current_item>.<identifier_on_junction_table_related_to_category_id>.<relation_field_name_to_display>
I realise that this is an old post, but it might help someone looking for the answer.
To select only the relational data use
?fields=category.*
This shows only the related category field of the blog article.
Related
For example, if there is a rest api for a shop system to add articles to my shopping cart without knowing the id, what would be the most restful way to design the url to call and what about the serverside implementation? I know there is some flexibility when designing rest apis, but what is "state of the art"?
Lets say my database does have the table "articles", "shoppingcarts", "article_pos".
articles (id, article_name, price, color),
shoppingcarts (id, description),
article_pos (id, shoppingcart_id, article_id)
Example to create an article:
POST "/api/shop/article/"
Request:
{
"article_name": "table",
"price": "100.00",
"color": "brown"
}
Example to get an existing article:
GET "/api/shop/article/4711"
Response:
{
"id": "4711",
"article_name": "table",
"price": "100.00",
"color": "brown"
}
But how I should design the url if I want to add article "4711" to the shopping cart?
Like this?
POST "/api/shop/shoppingcart/addArticle/4711?amount=1"
or Like this?
POST "/api/shop/article_pos/"
Request:
{
"shoppingcart_id": "1",
"article_id": "4711"
}
And how to get the article ID if a client doesn't know the ID (4711) but the articlename (table)?
But how I should design the url if I want to add article "4711" to the shopping cart?
POST /api/shop/shoppingcart/addArticleById/{4711}
fetch article details from article table, get the amount.
update shopping cart with these details
how to get article ID if a client doesn't know the ID (4711) but the articlename (table)?
POST /api/shop/shoppingcart/addArticleByName/{table}
fetch article details from article table, get the amount.
update shopping cart with these details
State Of the Art:
indentify resource by ID only, and use it for creating, updating details.
REST -> deals with resource first, hence a resource is first class citizen identified by a Id.
This question is language independent. Let's not worry about frameworks or implementation, let's just say everything can be implemented and let's look at REST API in an abstract way. In other words: I'm building a framework right now and I didn't see any solution to this problem anywhere.
Question
How one can construct REST URL endpoint for intersection of two independent REST paths which return collections? Short example: How to intersect /users/1/comments and /companies/6/comments?
Constraint
All endpoints should return single data model entity or collection of entities.
Imho this is a very reasonable constraint and all examples of Hypermedia APIs look like this, even in draft-kelly-json-hal-07.
If you think this is an invalid constraint or you know a better way please let me know.
Example
So let's say we have an application which has three data types: products, categories and companies. Each company can add some products to their profile page. While adding the product they must attach a category to the product. For example we can access this kind of data like this:
GET /categories will return collection of all categories
GET /categories/9 will return category of id 9
GET /categories/9/products will return all products inside category of id 9
GET /companies/7/products will return all products added to profile page of company of id 7
I've omitted _links hypermedia part on purpose because it is straightforward, for example / gives _links to /categories and /companies etc. We just need to remember that by using hypermedia we are traversing relations graph.
How to write URL that will return: all products that are from company(7) and are of category(9)? In otherwords how to intersect /categories/9/products and /companies/7/products?
Assuming that all endpoints should represent data model resource or collection of them I believe this is a fundamental problem of REST Hypermedia API, because in traversing hypermedia api we are traversing relational graph going down one path so it is impossible to describe such intersection because it is a cross-section of two independent graph paths.
In other words I think we cannot represent two independent paths with only one path. Normally we traverse one path like A->B->C, but if we have X->Y and Z->Y and we want all Ys that come from X and Z then we have a problem.
So far my proposition is to use query strings: /categories/9/products?intersect=/companies/9 but can we do better?
Why do I want this?
Because I'm building a framework which will auto-generate REST Hypermedia API based on SQL database relations. You could think of it as a trans compiler of URLs to SELECT ... JOIN ... WHERE queries, but the client of the API only sees Hypermedia and the client would like to have a nice way of doing intersections, like in the example.
I don't think you should always look at REST as database representation, this case looks more of a kind of specific functionality to me. I think I'd go with something like this:
/intersection/comments?company=9&product=5
I've been digging after I wrote it and this is what I've found (http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api):
Sometimes you really have no way to map the action to a sensible RESTful structure. For example, a multi-resource search doesn't really make sense to be applied to a specific resource's endpoint. In this case, /search would make the most sense even though it isn't a resource. This is OK - just do what's right from the perspective of the API consumer and make sure it's documented clearly to avoid confusion.
What You want to do is to filter products in one of the categories ... so following Your example if we have:
GET /categories/9/products
Above will return all products in category 9, so to filter out products for company 7 I would use something like this
GET /categories/9/products?company=7
You should treat URI as link to fetch all data (just like simple select query in SQL) and query parameters as where, limit, desc etc.
Using this approach You can build complex and readable queries fe.
GET /categories/9/products?company=7&order=name,asc&offset=10&limit=20
All endpoints should return single data model entity or collection of
entities.
This is NOT a REST constraint. If you want to read about REST constraints, then read the Fielding dissertation.
Because I'm building a framework which will auto-generate REST
Hypermedia API based on SQL database relations.
This is a wrong approach and has nothing to do with REST.
By REST you describe possible resource state transitions (or operation call templates) by sending hyperlinks in the response. These hyperlinks consist of a HTTP methods and URIs (and other data which is not relevant now) if you build the uniform interface using the HTTP and URI standards, and we usually do so. The URIs are not (necessarily) database entity and collection identifiers and if you apply such a constraint you will end up with a CRUD API, not with a REST API.
If you cannot describe an operation with the combination of HTTP methods and already existing resources, then you need a new resource.
In your case you want to aggregate the GET /users/1/comments and GET /companies/6/comments responses, so you need to define a link with GET and a third resource:
GET /comments/?users=1&companies=6
GET /intersection/users:1/companies:6/comments
GET /intersection/users/1/companies/6/comments
etc...
RESTful architecture is about returning resources that contain hypermedia controls that offer state transitions. What i see here is a multistep process of state transitions. Let's assume you have a root resource and somehow navigate over to /categories/9/products using the available hypermedia controls. I'd bet the results would look something like this in hal:
{
_links : {
self : { href : "/categories/9/products"}
},
_embedded : {
item : [
{json of prod 1},
{json of prod 2}
]
}
}
If you want your client to be able to intersect this with another collection you need to provide to them the mechanism to perform this. You have to give them a hypermedia control. HAL only has links, templated links, and embedded as control types. let's go with links..change the response to:
{
_links : {
self : { href : "/categories/9/products"},
x:intersect-with : [
{
href : "URL IS ABSOLUTELY IRRELEVANT!!! but unique 1",
title : "Company 6 products"
},
{
href : "URL IS ABSOLUTELY IRRELEVANT!!! but unique 2",
title : "Company 5 products"
},
{
href : "URL IS ABSOLUTELY IRRELEVANT!!! but unique 3",
title : "Company 7 products"
}
]
},
_embedded : {
item : [
{json of prod 1},
{json of prod 2}
]
}
}
Now the client just picks the right hypermedia control (aka link) based on the title field of the link.
That's the simplest solution. But you'll probably say there's 1000's of companies i don't want 1000's of links...well ok if that;s REALLY the case...you just offer a state transition in the middle of the two we have:
{
_links : {
self : { href : "/categories/9/products"},
x:intersect-options : { href : "URL to a Paged collection of all intersect options"},
x:intersect-with : [
{
href : "URL IS ABSOLUTELY IRRELEVANT!!! but unique 1",
title : "Company 6 products"
},
{
href : "URL IS ABSOLUTELY IRRELEVANT!!! but unique 2",
title : "Company 5 products"
},
{
href : "URL IS ABSOLUTELY IRRELEVANT!!! but unique 3",
title : "Company 7 products"
}
]
},
_embedded : {
item : [
{json of prod 1},
{json of prod 2}
]
}
}
See what i did there? an extra control for an extra state transition. JUST LIKE YOU WOULD DO IF YOU HAD A WEBPAGE. You'd probably put it in a pop up, well that's what the client of your app can do too with the result of that control.
It's really that simple...just think how you'd do it in HTML and do the same.
The big benefit here is that the client NEVER EVER needed to know a company or category id or ever plug that in to some template. The id's are implementation details, the client never knows they exist, they just executed Hypermedia controls..and that is RESTful.
For designing and creating a RESTful API the following question occurs:
The API supports GET (for queries), POST (for creating), PUT (for updates) and DELETE (for deleting).
Lets assume in the database we have an article and a shop both already existing.
Now we need a rest call to link the article instance to the shop instance. Which of the following solutions is the best / most clean REST design:
/shop/id/article/id/ --> with POST
/shop/id/article/id/ --> with PUT
/shoparticlerelation/ --> with POST (object with ids in body)
/shoparticlerelation/ --> with PUT (object with ids in body)
If there is no clear answer or all solutions are equally good this may also be a valid answer if there is a clear argumentation why.
I presume in this situation you already have a collection of shops and a collection of articles, and you just wish to link two together.
One option is to expose a more db like 'resource' that presents this link, and have operations like
POST /shopArticleLinks HTTP/1.1
{ "shop" : xxx,
"article: YYY
}
I would personally look to expose it as a property of the shops and/or articles in a more natural manor, like
PUT /shop/<ID> HTTP/1.1
{ /* existing details */
"articles": [ /* list of articles */ ]
}
I've used JSON there, but of course use what ever format you want to use. I've also stuck with using PUT as you stated, but keep in mind that with PUT you should send a full replacement for the new modified version, PATCH can be used to send partial updates, but then you need to consider how you want do that, may something like
PATCH /shops/<ID>/articleLinks HTTP/1.1
{ "add" : [],
"remove : []
}
Don't forget that server side you can look at what articles are being refereed to and ensure they have a proper back pointer.
Additional thoughts
Regarding the second method, where you expose the link as a property of the shop and/or article resources. Keep in mind that it is perfectly acceptable (and in this case rather appropriate) that when you update the links in a given shop that the links in the corresponding articles are also updated.
/shop/id/article/id/
You cannot use this because at the moment you want to link them, this endpoint doesn't (or at least shouldn't) yet exist. It is the action of linking them together that should define this endpoint.
/shoparticlerelation/
You should not use this because a shoparticlerelation is not a resource / entity. Usually with rest, every named url segment represents a resource that can be CRUD-ed. /shops is a good example and so is /articles but this one isn't.
I suggest the following:
Define the following endpoints
/shops for POSTing new shops
/shops/id for operating on a single shop
/articles for POSTing new articles
/articles/id for operating on a single article
Then to link them together you can do a so called PATCH request, to update a shop's articles, or an article's shops:
PATCH /shops/1 HTTP/1.1
{
"attribute": "articles",
"operation": "add",
"value": "8" // the article id
}
and
PATCH /articles/9 HTTP/1.1
{
"attribute": "shops",
"operation": "add",
"value": "1" // the shop id
}
Based on your comments I made the assumption that an Article model has a list of Shops as attribute, and vice-versa, making this approach valid.
A PATCH request is used to modify an existing resource by specifying how and what to update. This is different from a PUT because a PUT replaces the entire resource with values from the request, however PATCH is only used to modify (not replace) a resource.
I am looking for a more detailed list of possible API responses when using Yodlee's REST API. Think of it as an XSD response but for a JSON string. I want to know if there are possible data elements that are not listed Yodlee's JSON response examples.
The only info I can really find so far is here.
When I review these examples, it appears that the example JSON responses do not fully describe every field.
Here is part of the getItemSummaryForItem1 JSON example for maturityDate element
"maturityDate":{
},
It looks like there is an array, but the possible data elements for that maturityDate array are undeclared. Then later on maturityDate is shown to be:
"maturityDate":{
"date":"0014-02-01T00:00:00-0800",
"localFormat":"dd/MM/yyyy"
},
And then in another example from getUserTransactionCategories
{
"categoryId":31,
"categoryName":"Retirement Income",
"transactionCategoryTypeId":2,
"isBudgetable":1,
"localizedCategoryName":"Retirement Income",
"isHidden":false,
"categoryLevelId":3
},
Based on that I would think all possible data elements are there.
But then there is another one which introduces the childCategory data element
{
"categoryId":2,
"categoryName":"Automotive Expenses",
"isDeleted":0,
"transactionCategoryTypeId":4,
"isBudgetable":1,
"localizedCategoryName":"Automotive Expenses",
"isHidden":false,
"categoryLevelId":3,
"childCategory":[
{
"categoryId":5641,
"categoryName":"1_SubCategory1",
"categoryDescription":"Subcategory desc1",
"isDeleted":0,
"isBudgetable":0,
"localizedCategoryName":"1_SubCategory1",
"isHidden":false,
"parentCategoryId":2,
"categoryLevelId":4
}
}
Thanks!
Yodlee team is working on to get this details documented, this is a time taking process and will be soon available over their portal. Meanwhile, is there any specific field or API response for which you are looking to get all the child elements which will help you out without blocking your integration?
Im having an issue where I cant decide how to procced on this matter.. and I need to know if there is any standard way to solve this.. or if you guys have any great input for this matter.
The thing is that I have started to build a very basic API for learning purpose
The API is a simple Music store.. where the store has some Albums which requires and artist.
So the Relationship is Artist <--- 1 ----- * ---> Albums and for an album to exist its required that that the album has an artist. But the artist doesnt require and Album.
Now to the problem...
Due to this relationship if I want to create a new Album.. I would have to post the album data.. AND the entire Arist-data..not just the ID of th artist.. but the whole Artist.. which doesnt seem very effective if you ask me.. since that a whole lot of unnecessary.
So as I see it there is two ways to solve this...
either I just post the entire album-data/object and allows the Artist-data for the object to only contain an ID which then reference to the artist.
So instead of posting:
{
"Name":"AlbumName",
"Description":"Some description for the album",
"ReleaseYear": "1992",
"Artist" {
"Name":"Some artist",
"Id":"12345",
"Biography":"Lorem ipsum dolor sit amet"
}
}
I would do this:
{
"Name":"AlbumName",
"Description":"Some description for the album",
"ReleaseYear": "1992",
"Artist" {
"Id":"12345"
}
}
Option number two is to actually have a route/url thats specific for this...
for instance:
/api/artist/{artistid}/album
And then simply post an album-object to that url..
But as I said.. Im really not sure of whats right and wrong here.. or is there any standard way of handling this?
Thanks in advance!
I would suggest something like this.
POST /musicstore/artist/343/albums
{
"Name":"AlbumName",
"Description":"Some description for the album",
"ReleaseYear": "1992",
}
The act of creating a resource as a child of the collection of albums for the artist 343 implicitly creates the relationship between the artist and the album. There is no need to specify it in the payload.
Albums and Artists are two separate entities, you shouldn't post all the artist data into Albums, just its ID.
Therefore you first create the artist if it doesn't exist, and after that you post the album details, artist_id being one of its properties.