RESTful Proposal

[philinthecloud]

All

Here is my proposal, for discussion, about how I currently see the FREME Service being exposed and consumed. This is draft.

I think it is important that FREME have a consolidated endpoint such as: https://freme.eu/api/v1/

Each service could then have a uniform interface like: https://freme.eu/api/v1/elink https://freme.eu/api/v1/etranslation https://freme.eu/api/v1/eentity

I don't have a proposal for the uri's below this but would like to discuss.Maybe for machine translation: https://freme.eu/api/v1/etranslation/<from_lang>/<to_lang>/ or https://freme.eu/api/v1/etranslation?from=&to=

Through previous association with the Okpai Framework, there was a suggestion that a media representation like ITS JSON could be used. I admit I haven't looked at this in detail but I like the idea. I guess it could be just one of several Media Types that the services would support as appropriate to their response payloads.

More to come!

[pheyvaer]

Is there a specification for ITS JSON?

[jnehring]

Maybe a subdomain is a good way to clearly separate the API endpoints from the homepage, e.g.: https://api.freme.eu/v1/etranslation... To further specify the URLs and the parameters passed to the API we should wait until the requirements are created by the business partners.

According to our project proposal we should include NIF. But the more data exchange formats FREME supports the more useful it is. Here we have to wait for the requirements of the business partners also.

[jnehring]

@philinthecloud I can't find information about ITS JSON in your link and also not on Google. Can you provide another link / more information on ITS JSON?

[m1ci]

I think it is important that FREME have a consolidated endpoint such as: https://freme.eu/api/v1/

I also think versioning is important. We should agree on the versioning level. IMO we should perform versioning at the root level of each e-service.

My proposal: http://api.freme-project.eu/e-translation/v1.0/tilde http://api.freme-project.eu/e-entity/v1.0/dbpedia-spotlight

The rationale behind such versioning is that some services will/might evolve faster than others. Also I prefer having versioning such as v1.0, v2.0, v3.0, ... instead of 0.1, 0.2, 0.3, ... - such versioning was proposed in #16

[fsasaki]

+1.

• Felix

2015-05-13 10:51 GMT+02:00 Milan Dojčinovski notifications@github.com:

I think it is important that FREME have a consolidated endpoint such as: https://freme.eu/api/v1/

I also think versioning is important. We should agree on the versioning level. IMO we should perform versioning at the root level of each e-service.

My proposal: http://api.freme-project.eu/e-translation/v1.0/tilde http://api.freme-project.eu/e-entity/v1.0/dbpedia-spotlight

The rationale behind such versioning is that some services will/might evolve faster than others. Also I prefer having versioning such as v1.0, v2.0, v3.0, ... instead of 0.1, 0.2, 0.3, ... - such versioning was proposed in #16 https://github.com/freme-project/technical-discussion/issues/16

— Reply to this email directly or view it on GitHub https://github.com/freme-project/technical-discussion/issues/2#issuecomment-101578205 .

[jnehring]

API URLs implemented in #16 Versioning implemented in #12

All done