Django + React: Shared Model Consistency
Guilherme Leal
Exemple:
class Person(models.Model):
name = models.CharField(max_length=250)
gender = models.IntegerField(choices=MY_GENDER_CHOICES)
The concern I was talking about is HOW THE HELL am I going to tell the client that he only can use "this" or "that" limited set of fields or values? Even more, I want to teach the client how to discover this info, or simply put, share model specification between "client" and "server".
George Silva
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAOs3Lp6cp8vm403D0nWd%2B09-PDZKZQOcaBcU2dvNi7LUA--%2BeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Sigma Geosistemas LTDA
Guilherme Leal
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAGyPVTvwGXOamNKtsWGyaGG-q%2BkEHXg7BTw3QBxCCeU1P6w%3D8w%40mail.gmail.com.
Alceu Rodrigues de Freitas Junior
Never used Django REST Framework (DRF) before, but I guess you're trying to achieve something that should be handled by your API documentation.
It crossed my mind that you're looking for describing the payload your REST API expects and that should be done dinamically by the consumer. Never saw something like that for REST as exists for SOAP, but looks like somebody already spent time on that:
https://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
Never used though, you might want to experiment with it.
Besides that, some custom exception
explaining the problem when wrong values were provided should
help (at least the developers trying to use your API).
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
Guilherme Leal
Never used Django REST Framework (DRF) before, but I guess you're trying to achieve something that should be handled by your API documentation.
It crossed my mind that you're looking for describing the payload your REST API expects and that should be done dinamically by the consumer. Never saw something like that for REST as exists for SOAP, but looks like somebody already spent time on that:
https://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
Never used though, you might want to experiment with it.
Besides that, some custom exception explaining the problem when wrong values were provided should help (at least the developers trying to use your API).
Em 05/07/2017 15:17, Guilherme Leal escreveu:
I'm starting a new project that uses Django (with DRF) as backend and React as frontend but I have some concerns about data consistency across what the API endpoints might expect, and what the client with React could provide.
Exemple:
Lets say I have the following model:
class Person(models.Model):
name = models.CharField(max_length=250)
gender = models.IntegerField(choices=MY_GENDER_CHOICES)
If one would build an API endpoint for exclusively this model, the endpoint would answer with the fields 'name' and 'gender' everytime it would be "GETed", or would accept only the fields 'name' and 'gender' when "POSTed'. Furthermore, in both cases the 'gender' field have a limited set of values it can answer/accept.
The concern I was talking about is HOW THE HELL am I going to tell the client that he only can use "this" or "that" limited set of fields or values? Even more, I want to teach the client how to discover this info, or simply put, share model specification between "client" and "server".
One thing to note: I did looked over React+Relay+GraphQL. The features are almost exactly what I was looking for, but I did find it really really really overcomplex for the size of the project I have in mind.
Anyone have anything in mind to help or sujest?
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAOs3Lp6cp8vm403D0nWd%2B09-PDZKZQOcaBcU2dvNi7LUA--%2BeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5761e1ca-4887-22ae-cf27-8142f294a7ff%40gmail.com.
Melvyn Sopacua
On Wednesday 05 July 2017 16:34:49 Guilherme Leal wrote:
> DRF already have (something like) that [1]. Like I said to George, I'm
> trying to avoid the "request the metadata from the api call" aproach,
> as it tends to bloat the client with metadata requests.
There are no psychic clients available yet. Somewhere the client needs to be taught what is considered valid. You always need at least one request (complex, but limits meta data requests) to expose your API's parameters. The other way is to implement some lightweight protocol per endpoint - this is preferable if your API is large and clients typically use a small subset. A structured machine readable error response is the common way. But one can also use HTTP's OPTION method to do this.
While OPTION methods shall not be cacheable, nothing prevents you from implementing a versioning scheme and sending an api version header with each response. If the version deviates, the client knows to request the OPTION header again for future use.
Either way, you require at least one request to start the learning process.
--
Melvyn Sopacua