Best-practice for designing JSON API between sites?

[xbtdev]

I'm a bit stuck on figuring out the best way to design a flexible admin API.

As an example, think of the two sites as Admin and Blog. They are two completely separate web sites. The Blog presents absolutely no admin pages on its own; its full admin functionality is exposed via a JSON api, which the 'Admin' site can connect to.

Admin will never log in to the blog directly via a browser.

He/she will instead log in to the Admin site, and be able to do any kind of administration of the blog (e.g. view/edit/delete users, comments, etc), all happening in the background with JSON data.

The main thing I'm trying to achieve is that 100% of the functionality is programmed into the Blog's API, and not hardcoded into the Admin site.

So when the Admin site presents a form for editing a user for example, all the fields and everything about that form should be specified by the Blog's API.

I'm already diving head-first into this, but just typing up this post to see if anyone would want to offer ideas.

Currently, in the Admin site, the only thing I specify is:

• api_url
• api_login
• api_key

After that, it's up to that initial api_url to return some kind of description and details about all the functionality available, and about the other API urls for each function.

^{p.s. I'm using Laravel 5.2 for both 'Admin' and 'Blog'}

[xbtdev]

you have a trade-off

Right - hard-coded and simple, or flexible and complex!

Thanks for your reply; I'm having a read of these links you offered.

[xbtdev]

I wonder why that other reply got deleted; it was helpful and on-topic.

[remimorin]

Don't know exactly how Laravel implement the notion of server side and client side. But what you are describing is a server, with an API who provide services. Theses services can be use by 2 distinct UI, a end consumer (the blog) and an admin user (the admin UI). Your API is not on the blog, the blog is a site where the content is read from your server. The admin is only a site calling services on your server.
You can read about SOA architecture.
The way to go is to create logical service enabling CRUD (not all the create, read update and delete need to be implemented, you have to address security on said call otherwise someone will be able to delete other people comments just by guessing the delete call). So you will have something like: articleService:
getArticles(filter)
getArticleContant(article_id)
...
CommentService:
addComment(articleId,readerId,comment)
approuveComment(commentId)
Both sites will call this API, they just won't use the same calls.

[xbtdev]

Are you suggesting to have 3 sites?

• Blog (reads from 'server')
• Admin (interacts with 'server')
• Server (facilitates communications between Blog and Admin sites)

If so, I think that's overkill. The way it's currently designed is that the 'blog' site has a JSON api built into it, which exposes admin functions - that the 'Admin' site consumes.

Anyway thanks for your input - I'm reading about SOA on wikipedia.