Road map for OFN's API?

[oeoeaio]

@luisramos0

Is it not simple to “start fresh” with our API but using adapters/redirects to the spree API?

Possibly, but I don’t have my head fully around how that would work in practice. I’m sure it’s workable.

@luisramos0

I think you are saying that, for example, controllers/ShopController should be in controllers/api?

Yeah, mostly, but I think the #show action is still dealing with html, so we need to decide which parts to move across.

@luisramos0

I wonder why is stuff in views/api not in controllers/api. Can we set a rule that every view or controller that is rendering JSON goes into controller/api?

There are no controllers in views/api these are just templates used by API controllers to render json. That seems like the logical place to put them to my Rails brain.

@luisramos0

Also, I am not sure how app/serializers/api are used. Are these only used in AMS injection or are they part of some API?

They are used in much the same way as the templates. They are used to render json via APIs, but they can also be used for injection of data into the DOM. They are kind of like bloated serialisers that also perform the function of a decorator.

@luisramos0

Can you point to the code where those 3 APIs are implemented?

Ok, what I am thinking of as “Spree’s API” is almost entirely contained within the spree gem, but we are making some changes within our own app/controllers/spree/api.

What I am calling the OFN’s “Front-end API” is everything within app/controllers/api, but it should probably include a bunch on stuff that is currently sitting in app/controllers that is behaving like an API. Any action that responds to json should probably be moved over to app/controllers/api.

What I am calling OFN’s “Back-end API” is everything in app/controllers/admin/api but also HEAPS of stuff that currently lives in app/controllers/admin. In the same way as the front-end, we should probably move every action that responds to json into app/controllers/admin/api.

@luisramos0

Can you map them into these folders with RABL files in the OFN code base?

Kind of. The vast majority of the OFN’s API uses AMS instead of RABL to render json. There is a bit of a hangover from a short period where we started using RABL before we decided on AMS. I’m not 100% sure but I’d be surprised if any of the templates in app/views/api or app/views/admin/json are actually used any more, I didn’t even know app/views/open_food_network existed so I have no idea about that. I think quite a lot of the templates in app/views/json are probably still used by controllers in both app/controllers and app/controllers/api but I can’t be sure. As you’ve noted, everything in app/views/spree/api is likely to be an override of spree code.

@luisramos0

Can you understand and explain each of these folders and what are the good/new ones and what are the old/bad ones?

All bad as far as I am concerned, apart from the spree overrides which we don’t have much choice about. I try to replace RABL templates with AMS whenever I encounter them.

@luisramos0

From what I understand there are these 5 places with rabl files plus all the controllers that also take and produce json, plus AMS injectors…

I just want to be clear that at the moment AMS is our preferred tool for producing json from an object. I’m sure there are better tools but at the moment it’s the best we’ve got. We do use AMS for injection, but personally I try to avoid that practice wherever possible, and I do not consider that its primary purpose.