Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

An API is available for 3rd party interactions #280

Closed
pmackay opened this issue Nov 2, 2014 · 10 comments

Comments

@pmackay
Copy link
Contributor

commented Nov 2, 2014

Providing a full documented API is a long term goal, to support interactions from other websites and mobile apps.

Review

There are a number of questions I have about the current state of APIs and use of JSON:

  • Is the intent to move everything to AMS instead of RABL?
  • Could the use of the representation module that uses .rep files also get replaced by AMS?
  • Why do read-only operations on the /api need a product key? Could the key only be needed for write operations?
  • Would it be possible to define a full API accessible via an /api endpoint and use that instead of routes ending with .json? Seems quite mixed currently. What implications would this have?

@pmackay pmackay added the story label Nov 2, 2014

@pmackay pmackay added this to the OFN UK Backlog milestone Nov 2, 2014

@RohanM

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2014

Hey Paul,

  • Yes, we're intending to move everything from RABL to AMS. AMS is significantly faster, and migration has thus far been straightforward.
  • Yes, representative and the .rep files that go along with it should be moved to AMS, too.
  • Most of the /api endpoints are provided by Spree out of the box. So read-only operations need a key because that's a requirement that Spree enforces. I'm not sure we can drop it without some careful consideration though, since we don't want to leak data (ie. products, users, etc.) that a public user wouldn't have access to. Long-term, it'd be worth considering whether to write our own API from scratch rather than trying to build on the one Spree provides.
  • I'm not quite sure what you're asking in this question. What are the two approaches that you're seeing? Could you expand a little?
@pmackay

This comment has been minimized.

Copy link
Contributor Author

commented Nov 5, 2014

@RohanM The last question is related to the places where data is retrieved via a /foo/bar.json call, usually for the purpose of Angular updating of a page. I'm wondering if it makes sense to transform that into /api/foo/bar, for consistency? But I could see there may be reasons not to do this, particularly the need for a key in the API!

@wvengen

This comment has been minimized.

Copy link

commented Dec 14, 2015

wrt AMS: is the performance really that bad to to use something else than Spree here? In spree/spree#5971 (comment) some people ponder whether Spree should migrate.

@pmackay

This comment has been minimized.

Copy link
Contributor Author

commented Dec 14, 2015

to to use something else than Spree here?

Can you expand on what you mean by this?

@wvengen

This comment has been minimized.

Copy link

commented Dec 14, 2015

Spree is using RABL. As a (new) developer I would expect some similarity in approaches between Spree and OFN.

@pmackay

This comment has been minimized.

Copy link
Contributor Author

commented Dec 14, 2015

@RohanM might need to chip in. This is an old issue and I started some work on harmonising but didnt get far. Things might have changed anyway since then. I figured it was good to be consistent within the OFN codebase (which was a mix) irrespective of what Spree uses.

@wvengen

This comment has been minimized.

Copy link

commented Dec 14, 2015

👍 for harmonising within OFN. I might start working on API stuff, so it would be useful for me to know which approach fits best for us.

@wvengen

This comment has been minimized.

Copy link

commented Dec 15, 2015

Related: #287

@wvengen

This comment has been minimized.

Copy link

commented Dec 17, 2015

I discovered the many other AMS files, and can see it makes sense to use that. Especially with Rails 5 preferring AMS as well. Currently I'm experimenting with rendering RABL from within AMS, so that we can use the same JSON format for addresses and images, for example, within our own objects (like an enterprise) - without having to copy that in AMS.

@lin-d-hop

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2017

Moved to Discourse wishlist #gitcull2017
https://community.openfoodnetwork.org/t/road-map-for-ofns-api

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.