How do we feel about allowing formatters in API?
Created 7 years ago by ryanthompsonHow do we feel about allowing formatters in API? Could restrict them by scope but for internal consumption it could be really awesome.
{
"data": [
{
"id": 1,
"sort_order": 1,
"created_at": "11/14/2016",
"created_by": null,
"updated_at": "2016-11-15 02:47:12",
"updated_by": 1,
"deleted_at": null,
"email": "ryan@pyrocms.com",
"username": "admin",
"display_name": "Administrator",
"first_name": null,
"last_name": null,
"activated": 1,
"enabled": 1,
"permissions": null,
"last_login_at": "2016-11-15 02:47:12",
"remember_token": "xrsBkfawH8Zrrw3g1QoFQD0g9w1UdC4ccXt43b6ArnMWxYOhSCteFVlFxlfE",
"activation_code": null,
"reset_code": null,
"last_activity_at": "2016-11-14 08:38:51",
"ip_address": "::1",
"avatar": "https://www.gravatar.com/avatar/cd7e95aa74ded76c1d92374b20e5c34c?"
},
{
"id": 2,
"sort_order": 2,
"created_at": "11/14/2016",
"created_by": null,
"updated_at": "2016-11-14 06:37:03",
"updated_by": null,
"deleted_at": null,
"email": "demo@pyrocms.com",
"username": "demo",
"display_name": "Demo User",
"first_name": null,
"last_name": null,
"activated": 1,
"enabled": 1,
"permissions": null,
"last_login_at": null,
"remember_token": null,
"activation_code": null,
"reset_code": null,
"last_activity_at": null,
"ip_address": null,
"avatar": "https://www.gravatar.com/avatar/56022a3d51817ef1e5d20b5f667ac4ff?"
}
],
"pagination": {
"total": 2,
"per_page": 15,
"current_page": 1,
"last_page": 1,
"next_page_url": null,
"prev_page_url": null,
"from": 1,
"to": 2
}
}
POST I think would be weird cause it's the same request - it's just some additional criteria. Switching verbs for that reason seems a little odd IMHO. Formatters could be used for laziness - could be nice for getting system output (active locale / currency configuration).. Hard saying really.
The way I see it is that the wildly popular Dingo API has transformers (presenters for your JSON API basically) and Pyro basically has the same in the form of field types / presenters. Why not reuse that presenter logic and make it available 😊
I may call it something different but.. the gist is the same.
@lckamal it's extremely close - I have an important patch/adjustment to make to the way auth is handled and it will be ready.
When we went 3.2 and used Laravel 5.3 - I did not update the auth service to use Guards so we need to accomodate that since API module uses an API guards rather than normal authentication.
@ryanthompson Thanks for the update. It would be great if you can post on slack after its ready.
Yea I like this. Looks sexy. And for someone who deals with APIs in android, this would make request a lot easier / more granular.
I suppose I don't really understand why a more complicated API call would be helpful. Seems like an API is designed to be consumed by a program that could easily do anything and more than a formatter in the API URL could do. I'm not saying it shouldn't be done, I'm just struggling to think of a good reason to complicate the API like that.