Routes for web application's resource pages and API

Developing a web application using a front-end Javascript framework that is getting the data from the application's API, and I'm unsure on the appropriate structure for URL routing when things overlap...

A regular resourceful object would look something like this, which follows RESTful principles:

• GET /posts - Displays a page with a list of posts
• POST /posts - Creates a new post
• GET /posts/create - Displays a page with a form to create a new post
• GET /posts/{id} - Displays an individual post's page
• GET /posts/{id}/edit - Displays a page with a form to edit an existing post
• PATCH /posts/{id} - Edits an existing post
• DELETE /posts/{id} - Deletes an existing post

While this works fine for a regular web application, some of the GET requests return fully qualified HTML web pages, which overlaps with that of an API:

• GET /posts - Return a list of posts in JSON
• GET /posts/{id} - Return an individual post's details in JSON

What is the best way to handle an application that is to offer both of these functionalities? I can think of some solutions off the top of my head:

• Just rename some of the routes like GET /posts/all to return the page of all posts, and have GET /posts be the API version.
• Move the API functionality (the non-GET requests and returning JSON versions of the resources) to its own api/ route or subdomain, completely separating it from the views.

I'm more for the latter, but it still separates these relevant routes from the rest of the resource, although if it's just a view I'm not sure if that will matter so much.

What is the best practice for a situation like this?

via I'm Liam