If possible I'd like to query a related model using a query parameter rather than overwriting a blueprint action. I'm not sure if I need to manually populate an association for this to work.
I have two related models: Idea and Tag. An Idea can have many Tags, and a Tag can be associated with many Ideas (M-M association). I would like to query all Ideas that are associated with a given Tag name.
I had this working in the past, but now the result is always an empty array. I looked through my git history and I have two different possible solutions that I have used in the past
Blueprint Endpoint (worked in the past?):
http://localhost:1337/Idea?tags.text[]=GIS
http://localhost:1337/Idea?tags.text=GIS
Example Idea instance (other associations removed for brevity):
{
"tags": [
{
"text": "GIS",
"description": "Geographic Information Systems involves the association of location and attribute data, data collection, and analysis.",
"approved": true,
"createdAt": "2015-08-26T13:27:19.593Z",
"updatedAt": "2015-08-26T13:29:44.209Z",
"id": "55ddbeb71670cf062be4e5c0"
}
],
"title": "First Idea",
"description": "Let's all do some more GIS!",
"status": "Proposed",
"createdAt": "2015-08-26T13:30:03.238Z",
"updatedAt": "2015-08-26T13:30:03.240Z",
"id": "55ddbf5b1670cf062be4e5c1"
}
Related
I am trying to create a state for existing work item.
For Get, the url will show the list of States under Bug.
But am facing an issue when I do Post with json.
https://{server}/{collection}/_apis/work/processes/{processid}/workItemTypes/Microsoft.VSTS.WorkItemTypes.Bug/states?api-version=5.0-preview.1
Json:
{"name": "Test-Status", "color": "007acc", "stateCategory": "InProgress", "order": 3 }
Below is the error details
Http - 404 - NotFound
{ "$id": "1", "innerException": null, "message": "VS402805: Cannot
find work item type with reference name
'Microsoft.VSTS.WorkItemTypes.Bug' in process named
'dcdcc713-ebc6-4940-aa9d-d6c9d3e00e39'.", "typeName":
"Microsoft.TeamFoundation.WorkItemTracking.Server.Metadata.ProcessWorkItemTypeDoesNotExistException,
Microsoft.TeamFoundation.WorkItemTracking.Server", "typeKey":
"ProcessWorkItemTypeDoesNotExistException", "errorCode": 0, "eventId":
3200 }
Any help regarding this is appreciated.
The problem should be:Microsoft.VSTS.WorkItemTypes.Bug. I think you need use the format like processName.typeName. In addition the original process cannot be customized , only the inherited process can be customized.
Here I test your api in postman,it can work well.
I had the same problem.
When you create a new process, all the Work Item Types from the Parente process (Agile, Scrum, etc.) starts with the Microsoft.VSTS.WorkItemTypes.(Epic, Bug, etc.) and you can't modify it, you will have the error:
"VS402805: Cannot find work item type with reference name 'Microsoft.VSTS.WorkItemTypes.Bug' in process name ..."
To solve this, you just need to create a new work item type that inherits that work item type that you want to use, post example:
POST https://dev.azure.com/{organization}/_apis/work/processes/{processId}/workitemtypes?api-version=6.0-preview.2
{
"referenceName": "ProcessName.Issue",
"name": "Issue",
"description": "your description",
"color": "B4009E",
"icon": "icon_traffic_cone",
"inheritsFrom": "Microsoft.VSTS.WorkItemTypes.Issue"
}
I hope it helps.
Have a nice day!
Say I have a REST API for accessing user notifications. I have an endpoint for getting all notifications:
GET https://server:443/api/notifications
Which returns the following response:
[
{
"status": "unread",
"_id": "5db8228d710ab4b1e33f19b2",
"title": "Some title",
"time": "2019-10-29T11:29:17.402Z",
"details": "Some details...",
"user": "user1"
},
{
"status": "unread",
"_id": "5db8228d710ab4b1e33f19b3",
"title": "Some title",
"time": "2019-10-29T11:29:17.411Z",
"details": "Some other details",
"user": "user2"
},
]
Now, I'd like to also be able to retrieve the amount of notifications for each user in a single request, for which the response will be something like:
[
{
"user": "user1",
"count": 1
},
{
"user": "user2",
"count": 1
},
]
What would be the best way, in terms of REST conventions, to do that?
What would be the best way, in terms of REST conventions, to do that?
REST really doesn't answer that. REST tells you that you have resources, but it doesn't actually offer any opinion on where the "boundaries" of your resources should be.
Again, think "web pages". You could add your summary to the web page that describes notifications, and that would be fine. Or you could decide that the notifications are described on one web page, and the summary on a different web page, and that would be fine.
What REST does tell you is that caching is important; so if you think the cache controls for summary data should be different from notification data, then you want to be thinking about separating that data into a different resource. If you think the summary data and the notification data needs to be synchronized, then its more likely that they belong as part of the same resource.
Of course, there's nothing in REST that says you can't have multiple resources that return the "same" data.
If you wanted the summary to be part of the notifications resource, and also wanted that information to be independently identifiable, then you would use a fragment to describe the summary "sub-resource"; perhaps https://server:443/api/notifications#summary.
Currently, I'm working on new product and making REST API for both - public and internal needs. I started with {json:api} specification and I was pretty happy with it until I faced some questions I cannot find answers to.
According to JSON API specification, every resource MUST contain id.
http://jsonapi.org/format/
Every resource object MUST contain an id member and a type member. The values of the id and type members MUST be strings.
And that's fine in many cases but not all.
Most of our endpoints are about "resources"
If I ask for a "things" collection (http://example.com/things)
{
"data": [{
"type": "things",
"id": "1",
"attributes": {
"title": "first"
},
"links": {
"self": "http://example.com/things/1"
}
}, {
"type": "things",
"id": "1",
"attributes": {
"title": "second"
},
"links": {
"self": "http://example.com/things/2"
}
}]
}
If I ask for a single "things" resource (http://example.com/things/1)
{
"data": {
"type": "things",
"id": "1",
"attributes": {
"title": "first"
},
"links": {
"self": "http://example.com/things/1"
}
}
}
But what to do with endpoints which are not about resources and does not have ID?
For example, in our application, there is an endpoint http://example.com/stats which should return stats of current logged in user. Like
{
"active_things": 23,
"last_login": "2017"
}
There is no id for this "resource" (it's not actually a resource, is it?). Backend just collects some "stats" for logged in user and returns an object of stats. There many endpoints like this in this application, for example, we have Notification center page where the user can change email addresses for different notifications.
So frontend app (single-page-app) first has to get current values and it sends the request to GET http://example.com/notification-settings.
{
"notifications_about_new_thing": "arunas#example.com",
"notification_about_other_thing": "arunas#example.com"
}
And there are many more endpoints like this. The problem is - how to return these responses in JSONAPI format? There is no ID in these endpoints.
And the biggest question is - why nobody else is facing this issue (at least I cannot find any discussion about this)? :D All APIs I ever made has some endpoints which don't have "id".
I have two ideas, first is to fake id, like "id": "doesnt_matter", the second - do not use json-api for these endpoints. But I don't like both of them.
Think RESTfully and everything can (must) be a resource. There is no "logged in" user as there are no sessions in RESTful APIs as they are stateless. There's no session state maintained between REST API invocations, so you have to be explicit about who the user is.
In this case, the resource is the user who has some stats attributes (in the simple case) or perhaps a relationship to a separate stats relationship (more complicated, not shown):
GET /users/1234
{
"data": {
"type": "users",
"id": "1234",
"attributes": {
"name": "etc.",
"active_things": 23,
"last_login": "2017"
}
}
}
I'm no JSON API expert- but it's worth noting that while JSON API is a concrete specification, it is not the same thing as JSON, nor as a REST API. If you don't like its semantics, I agree with commenters who argue, "Don't use it." If you are going to use JSON API, do so in a compliant way, where every response is a resource; every resource has an ID and a type; and additional information is supplied as attributes of the resource.
Toward your question, I'm thinking about something similar where my application returns computation results. Now on the one hand, these are not strictly "resources" and so I've been toying with the idea of returning the raw result as an array (which I believe would be valid JSON, with a caveat), e.g:
[ 47 ]
On the other hand, there is the idea that the results are the results of a computation that the client specified RESTfully, in which case one of the following two cases is likely true:
The same request submitted later is likely to have the same result. This suggests that in fact the result really is a resource.
The same request submitted later is likely to have a different result. This suggests that the client may want to track how results change for various queries, and so at least the query parameters should be part of the response.
In both cases, the response really is a 'result' object, and even though it doesn't have an ID per se, it does have an identity. If nothing else fits, the ID could be the query that generated the response.
This seems RESTful to me. User #n2ygk suggests that this is not correct as regards the JSON API spec, that an ID should simply be a unique ID and not have another semantic interpretation.
I'd love to hear other perspectives.
My API contains a Book entity which represents a collection of several possible BookContent depending on the language. A BookContent is another entity with the attributes Title and Content, which both depend on the Language.
Should a Book look like:
1)
[
{
"language": "English",
"title": "First title",
"content": "First content"
},
{
"language": "French",
"title": "Premier titre",
"content": "Premier contenu"
}
]
or like:
2)
{
"English": {
"title": "First title",
"content": "First content"
},
"French": {
"title": "Premier titre",
"content": "Premier contenu"
}
}
The option 1):
produces "self-contained" elements, i.e. each object contains all the information.
The language attribute can contain any Unicode character (whereas as a key it cannot).
is the only available option if the content depends on multiple criteria, i.e. language and year.
creates a clearer separation between the two entities. For example, it makes it easier to replace each element by its ID, if we were to decide not to embed the BookContent entity anymore but only return the BookContent ID.
is probably more familiar to developers using my API, since I believe it is more common to find this kind of structure in other REST APIs.
The option 2):
produces smaller elements.
makes it faster to look for the elements according to the language without traversing through the whole collection.
This is a general question to know which one looks more like a "best practice", with no assumption on how the clients are querying/using the REST API, nor how much performance matters as opposed to flexibility, etc.
Which option is generally more often a "best practice"?
You state in your question that:
This is a general question to know which one looks more like a "best practice", with no assumption on how the clients are querying/using the REST API.
You are writing a REST service that is designed to help clients get information out - if that wasn't your aim, there'd be no point writing it. Because of this, the most important question you need to answer is "what information do clients want?". The answer to that will dictate the structure of your data, not "which one looks better?" - we're not your service's end users.
Personally, I'd opt for the first, simply because it would seem wrong to have an array called books.English in my object, it also allows for languages with characters outside of A-Z, and caters for books where the language is not known (or mixed). If simplicity of the individual book is key (and the list of languages is well-defined and finite), then consider:
[
{
"language": "English",
"books": [{
"title": "First title",
"content": "First content"
}]
},
{
"language": "French",
"books": [{
"title": "Premier titre",
"content": "Premier contenu"
}]
}
]
In essence, however, there's no single best practise for the data structures you're building other than "make them useful".
So, I'm using MongoDB for a project an I have a server that was used to do all the testing for my site and I used DBRef on a few tables and this created something like this:
"comment": {
"$ref": "user",
"$id": ObjectId("xxxx"),
"$db": "dev_server"
}
And now we have a new server for the actual production site. Since we where working with real information we exported the DB and placed it into a new one called "prod_server".
Now, the DBRef keeps like the one above. I've tried to update the value of the $db but i get this:
"comment": {
"$db": "prod_server"
"$id": ObjectId("xxxx"),
"$ref": "user",
}
And with this change the web crashes(mongo changes automatically to alphabetic order). I searched about this and found out that the order of the DBRef is important or else it won't work.
So that why the question: "How to change DBRef" and keep the right order?
I used the console and rockmongo for this and none of them worked.
Thank you