telescope
telescope copied to clipboard
[Post-services] Add `author`, `title`, `publishDate` fields to '/' route
Our current Post-services /
route will return an array of posts see JSON below.
[
{
"id": "33a8c63f31",
"url": "https://api.telescope.cdot.systems/v1/posts/33a8c63f31"
},
{
"id": "6f3d109b82",
"url": "https://api.telescope.cdot.systems/v1/posts/6f3d109b82"
},
{
"id": "3253659d90",
"url": "https://api.telescope.cdot.systems/v1/posts/3253659d90"
}
]
Since our React native app design uses a click and reads design. When fetching the list of posts, we have to do another fetch to get author
, title
, date
.
This is inefficient since it makes a lot of unnecessary requests, we only need to request post detail on click to a post.
The solution is to add author
, title
, and publishDate
to the object.
Sample JSON:
[
{
"id": "33a8c63f31",
"url": "https://api.telescope.cdot.systems/v1/posts/33a8c63f31",
"author":"",
"title":"",
"publishDate":""
},
{
"id": "6f3d109b82",
"url": "https://api.telescope.cdot.systems/v1/posts/6f3d109b82",
"author":"",
"title":"",
"publishDate":""
},
{
"id": "3253659d90",
"url": "https://api.telescope.cdot.systems/v1/posts/3253659d90",
"author":"",
"title":"",
"publishDate":""
}
]
Probably adding some kind of URL param to return a fully hydrated object is best (i.e., don't do it unless requested). For example:
-
GET /posts
returnsid
andurl
only (current behaviour) -
GET /posts?expand=1
returns some version of what you suggest above
This way you can opt into the extra calls this will require.
Probably adding some kind of URL param to return a fully hydrated object is best (i.e., don't do it unless requested). For example:
* `GET /posts` returns `id` and `url` only (current behaviour) * `GET /posts?expand=1` returns some version of what you suggest above
This way you can opt into the extra calls this will require.
I agree.
Hi,
Can I have this? I've already fixed this issue.
Does this fixed version look right?
Hi,
Can I have this? I've already fixed this issue.
Does this fixed version look right?
Welcome, great it seems what we want.
This use case is mainly for the mobile app.
Closed via #3771