On Monday 01 June 2015 14:49:18 Damian, Alexandru wrote: > On Mon, Jun 1, 2015 at 2:43 PM, Paul Eggleton <[email protected] > > wrote: > > > > Hi Alex, > > > > On Friday 29 May 2015 14:58:57 Damian, Alexandru wrote: > > > On Thu, May 21, 2015 at 11:25 AM, Michael Wood <[email protected] > > > > > > wrote: > > > > Conflating the web pages and the APIs into a single URL pattern/schema > > > > just doesn't make sense to me because: > > > > > > > > - We will have pages calling themselves with a different parameter > > > > (e.g. > > > > > > the tables pages) > > > > > > And this is quite ok, since it will return the same data, but in a > > > different format. The whole idea of REST is to allow a unique point of > > > entry for each resource - so the table data in HTML format and in JSON > > > format will be at the same URI. > > > > > > > - This is not how REST frameworks are implemented in any other > > > > application > > > > > > I've seen before > > > > > > I've taken the browsable-api from Django REST framework as model; which > > > has the same concept of exposing data in different formats based on a > > > GET > > > parameter > > > > > > http://www.django-rest-framework.org/topics/browsable-api/ > > > > > > > - In the future we may want to version the name-space e.g. > > > > /api/1.3/projects/ > > > > > > And this approach will make it easier - we will only have to port a > > > > single > > > > > set of URLs and not pairs for JSON and HTML content. > > > > > > > - Keeping the API self contained allows for greater future flexibility > > > > because it de-couples them from the page structure. > > > > > > Exactly my point - the HTML page structure is created in templates, > > > > while > > > > > the data itself is built in the view context; this approach enforces > > > > actual > > > > > encapsulation of data in the context, a issue we confronted in the past. > > > > I'm not sure you guys are talking about the same things. If this API is > > only > > for internal use by the application itself, fine - but if it's also for > > This not just internal, but also external support. > > > external applications, we probably don't want to break those external > > applications if we have to change the page URL structure. Unifying the > > page URLs and REST API URLs will force us to keep them the same, right? > > Yes, it will force us to keep them the same. It will also ease the > maintaining work.
So what do we do when we need to change the URL structure for the user-facing side but preserve the API for existing applications? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- _______________________________________________ toaster mailing list [email protected] https://lists.yoctoproject.org/listinfo/toaster
