You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the only way to identify a resource is by ID, I tried to imagine how it may work for composite keys (and non-ID keys in general) and made some preliminary work on the subject in this commit but it raises some questions regarding how it should be used.
It can generate something like: /books/1/book_i18ns/en_US/
Maybe it's more correct, i don't know. What do you think?
In both cases, there's an issue (#7) with creating the record in the known location.
And all that raises one more issue with getting the resourceName, at present, you can easily figure it out because it's either at the end (if it's not numeric) or before the id. If the number of primary keys is unknown then you either have to send that number alongside the request or use another method of figuring out the resource name, for the moment I chose the latter and count from the beginning of the URL. That's the only breaking change, you have to specify the root index, eg:
API::handle(1);
for URLs like /api/{:resourceName}/...
I would very much like your input on all that, maybe I'm completely off and you already have something better in mind. Thanks!
The text was updated successfully, but these errors were encountered:
Currently, the only way to identify a resource is by ID, I tried to imagine how it may work for composite keys (and non-ID keys in general) and made some preliminary work on the subject in this commit but it raises some questions regarding how it should be used.
Let's consider this db:
That's what Propel's
i18n
behavior generates.So the simplest way I see is this:
Which generates this resource URL:
/book_i18ns/1/en_US/
This is the way how it's done in the mentioned commit and it works quite nicely.
Or we can try and play with foreign keys:
It can generate something like:
/books/1/book_i18ns/en_US/
Maybe it's more correct, i don't know. What do you think?
In both cases, there's an issue (#7) with creating the record in the known location.
And all that raises one more issue with getting the
resourceName
, at present, you can easily figure it out because it's either at the end (if it's not numeric) or before the id. If the number of primary keys is unknown then you either have to send that number alongside the request or use another method of figuring out the resource name, for the moment I chose the latter and count from the beginning of the URL. That's the only breaking change, you have to specify the root index, eg:for URLs like
/api/{:resourceName}/...
I would very much like your input on all that, maybe I'm completely off and you already have something better in mind. Thanks!
The text was updated successfully, but these errors were encountered: