User tests: Successful: Unsuccessful:
Pull Request for Issue #34361 the GET part.
itemid is the alias ie type_alias com_contact.contact
+ the id
v1/content/articles/contenthistory/:id
v1/contacts/contenthistory/:id
no data retrieved
{
"links": {
"self": "http://dev4.loc/api/index.php/v1/contacts/contenthistory/1"
},
"data": [
{
"type": "history",
"id": "8",
"attributes": {
"version_note": "",
"save_date": "2021-06-07 08:28:20",
"editor_user_id": "996",
"character_count": "1558",
"sha1_hash": "31deaec71ad57388d01f47394fb722b62d9bc3f9",
"version_data": {
"id": "1",
"name": "Contact1",
"alias": "contact1",
"con_position": "aa",
"address": "aa",
"suburb": "aa",
"state": "aa",
"country": "",
"postcode": "",
"telephone": "12",
"fax": "13",
"misc": "",
"image": "",
"email_to": "aaa@aa.it",
"default_con": 0,
"published": "1",
"checked_out": null,
"checked_out_time": null,
"ordering": 1,
"params": "{\"show_contact_category\":\"\",\"show_contact_list\":\"\",\"show_tags\":\"\",\"show_info\":\"\",\"show_name\":\"\",\"show_position\":\"\",\"show_email\":\"\",\"add_mailto_link\":\"\",\"show_street_address\":\"\",\"show_suburb\":\"\",\"show_state\":\"\",\"show_postcode\":\"\",\"show_country\":\"\",\"show_telephone\":\"\",\"show_mobile\":\"\",\"show_fax\":\"\",\"show_webpage\":\"\",\"show_image\":\"\",\"show_misc\":\"\",\"allow_vcard\":\"\",\"show_articles\":\"\",\"articles_display_num\":\"\",\"show_profile\":\"\",\"contact_layout\":\"\",\"show_links\":\"\",\"linka_name\":\"\",\"linka\":\"\",\"linkb_name\":\"\",\"linkb\":\"\",\"linkc_name\":\"\",\"linkc\":\"\",\"linkd_name\":\"\",\"linkd\":\"\",\"linke_name\":\"\",\"linke\":\"\",\"show_email_form\":\"\",\"show_email_copy\":\"\",\"validate_session\":\"\",\"custom_reply\":\"\",\"redirect\":\"\"}",
"user_id": 0,
"catid": 4,
"access": 1,
"mobile": "12",
"webpage": "",
"sortname1": "",
"sortname2": "",
"sortname3": "",
"language": "*",
"created": "2021-06-07 08:28:20",
"created_by": "996",
"created_by_alias": "",
"modified": "2021-06-07 08:28:20",
"modified_by": "996",
"metakey": "",
"metadesc": "",
"metadata": "{\"robots\":\"\",\"rights\":\"\"}",
"featured": "0",
"publish_up": null,
"publish_down": null,
"version": "1",
"hits": 0
},
"keep_forever": "0",
"editor": "alikon",
"id": "8"
}
}
],
"meta": {
"total-pages": 1
}
}
Status | New | ⇒ | Pending |
you should pass 41 ie the article id not the version id
you should pass 41 ie the article id not the version id
That gives me a response indeed. It feels somewhat counter intuitive though. If I interpret the JSON:API correctly, an endpoint having an item specifier as part of the uri, is supposed to return a single item. An endpoint without an item specifier returns a list. Such an endpoint uses filters to restrict the list to a subset. So for this particular case I would expect
v1/content/articles/contenthistory
to return all history items.
v1/content/articles/contenthistory?filter[article_id]=41
to return all history items for the article with id 41.
But maybe my understanding of the JSON:API is wrong. Perhaps @wilsonge can give his two cents on the matter.
v1/content/articles/contenthistory?filter[article_id]=41 to return all history items for the article with id 41.
How about v1/content/articles/41/contenthistory . Reference https://jsonapi.org/recommendations/#urls-relationships (just a quick read, sorry if I'm making a stupid suggestion).
v1/content/articles/contenthistory?filter[article_id]=41 to return all history items for the article with id 41.
How about v1/content/articles/41/contenthistory . Reference https://jsonapi.org/recommendations/#urls-relationships (just a quick read, sorry if I'm making a stupid suggestion).
Not such a stupid suggestion, in my opinion. When I look at JSON:API - Fetching Resources, you see something similar in the third example: GET /articles/1/author
.
I have never had enough time to read https://jsonapi.org documentation but from beginning, but I always have the feeling that it's better url compare to what we are having at the moment (of course without fully understand JSON API and our current implementation of webservice)
v1/content/articles/41/contenthistory
does indeed sound more sensible. But we do have to be a bit careful because the ID needs to be unique for the content type. And contenthistory id 41 may be shared with id 41 of another content type.
Status | Pending | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-06-08 11:05:10 |
Closed_By | ⇒ | wilsonge | |
Labels |
Added:
?
?
|
I'm merging this because it functionally gets things working. However I 100% agree that we need to refactor the URLs for content history. But we can do this as a separate PR on top of this.
@alikon With existing history (version_id: 77, item_id: com_content.article.41), executing
v1/content/articles/contenthistory/77
gives me the following result: