Add routes for getting posts and a post

[humphd]

In #260 we're going to be adding the ability to store Posts in the Redis database. In #261 we're thinking about how to display the data in the UI. Once these are in, we'll want to be able to get the posts out of Redis via our web server.

We need some routes to allow for querying the database for posts, and an individual post, as JSON, something like:

• posts/ should return an array of IDs for all posts in the database. Later we can update this to support ranges and pagination (only requesting the last 10, or the next 20-30, etc).
• post/<id> given an ID of a post, get back JSON for that post

Until the work in #260 is done, this could return dummy data so the frontend team can start working on it. Reference what is happening in #259 to understand how this data should look.

[manekenpix]

Can I take this one?

[lucacataldo]

hey @manekenpix not sure if you've started working on this yet but try and keep in mind that pagination is something we should be handling at the same time. Also, I'm going to be working on the front end fetching of data from the server (#263) so we should try and stay on the same page in regards to how data will be formatted so that we can avoid creating more work for ourselves in the future. For now I'm going to be assuming an array of post objects (in JSON) is going to be returned and I've been using what @humphd wrote as abreakdown of attributes in #259 seen here:

I'll be keeping an eye on that thread for a PR and adjust accordingly but if you want to discuss anything regarding this feel free to hit me up in this thread or over in #263!

[humphd]

NOTE: those properties, names, etc are a guideline. If you all find that they need to be changed due to frontend, backend, or data needs, make changes.

[manekenpix]

@lucacataldo Excellent, thank you for this! I'll keep you posted with the development of this issue so we can coordinate on all that you mentioned in your comment (pagination, formatting, data structure...). Also, we should consider what @humphd mentioned, altering properties if needed.

[lucacataldo]

@humphd Of course! I just wanted to use it as a reference for some common ground to start on.

Also, @manekenpix, sounds good 👌

[lucacataldo]

Hey, @manekenpix Just so we're on the same page about structure and pagination:

I'm thinking each request includes a "page" query or parameter and the response is an object that contains an array of posts in it plus another key that specifies which page it is.

For example this is how I have my dummy data response setup:

[humphd]

A couple of thoughts:

1. updated and published should be real DateTime data, so we can use it in any way we want in the UI (e.g., show date, time, whatever).
2. for page, should we instead give you the range of posts you have? As in, "here are posts 50-65 of 100 posts"? A "page" doesn't really have a meaning, and we'll know the exact amount of posts we have.
3. Should /posts give back an Array of guids/URLs to get each /post/<id> vs. having it all in this one result? It could be massive.

[humphd]

Saw this the other day, it's a good read when thinking about how to design routes: https://github.com/microsoft/api-guidelines/blob/master/Guidelines.md

Also, there's a PR up right now by @KarlaChen and @haichuan0424 for the Redis side of this, see #332. One thing I was mentioning to them was that having the ability to request ranges of posts in the set (e.g., to implement paging) would be good.

It would be useful to consider that api design here, so they can get their code to support it.

[manekenpix]

@humphd thank you for the link, I just took a quick look at it and it's going to be very useful. Thank you!

I'll keep an eye on #332 while working on this one so both pieces can start working together right away once they're ready without having to make too many adjustments.

Also, you mentioned this in a previous message:

/posts give(s) back an Array of guids/URLs to get each /post/

I used this approach in another project and seemed to work well. I think we should go with that.

[humphd]

How is this coming? It's one of the more important pending issues we have, as it will connect the backend and frontend. I'd like to see some/all of it get in early this week if possible. If you need help, let me know.

[manekenpix]

@humphd It's almost done, I'll probably have a PR tomorrow or maybe later today.