django - Is bad practice to mix REST and RPC together? -

i'm new rest web services , used rpc. know advantages of rest reading several posts this one.

i developing server in django using django-rest-framework.

although have question (or questions):

i have model:

class poll(models.model):     questionstring = models.charfield(max_length=500, blank=true)     timetoanswer = models.integerfield(default=30)     startdate = models.datetimefield(null=true, db_column='startdate', blank=true)     token = models.charfield(max_length=20, blank=true, unique=true)  class pollaggregator(models.model):      name = models.charfield(max_length=135)     description = models.charfield(max_length=500, blank=true)     voterstoken = models.charfield(max_length=20, null=true, blank=true)  class pollpollaggregatorrel(models.model):     pollaggregator = models.foreignkey(pollaggregator, null=true, db_column='pollaggregatorid', blank=true)     poll = models.foreignkey(poll, null=true, db_column='pollid', blank=true) 

so can have single poll or can have bunch of polls aggregated in poll aggregator (i.e. room).

so created rest calls: polllist, polldetail, pollaggregatorlist, pollaggregatordetail. have problems design pollpollagregatorrel. of course can have pollpollagregatorrellist , pollpollagregatorreldetail , make normal post, get, update, delete. if want make new relation between poll , poll aggregator in rest style, do:

• check if pollpollagregator (list) exists poll id , filtered pollid
• if so, update item have new pollaggregator id
• if not create new pollpollagregator post

my first question is there easier , simpler way this?

if use rpc web service like:

• relate poll pollaggregator , use get_or_create pollpollaggregatorrel. update or create new pollpollaggregatorrel object.

so using rpc like, client uses 1 call versus rest needs call 2 times. in case seems simpler use rpc both server , client side.

second question is: bad practice use both rest , rpc in same api?

q1: think reasonable provide rest-style post operation either returns existing aggregator or creates new 1 required. which, logically, seems not unlike "rpc" service.

i think part of difficulty may designing rest "calls" (hint: they're not "calls", they're "resources") closely around underlying model. it's mistake i've made in past.

rest != crud.

a key benefit of rest allows interface separated model, server can change implementation without affecting clients. key benefit minimizes amount of information client needs know in advance in order perform operation. e.g. rest client should able discover resource uris needs use interacting "front resource" (by analogy "front page") of service.

so consider approach in there following resources cover describe above:

1. a service home page, representation contains links (or link templates) other resources (or returns links via http link headers)

2. a "poll collection" resource provides creation , access individual polls (e.g. returns list of polls, post creates new one)

3. individual polls, uris discovered though interactions "poll collection". get, put, delete might expect. i'm not sure if you'd need post these.

4. an "aggregation manager" resource associates polls aggregations (can poll belong more 1 aggregation? - description suggests not). post resource containing poll uri locate-or-create aggregation (or aggregations?) or create new one. might return list of existing aggregations.

5. individual aggregation resources uris discovered though interactions aggregation manager resource.

in description, pollpollaggregatorrel part of (current) implementation, not expose such through rest api. gives flexibility change internal implementation without affecting how clients use api. that's point of rest.

i'm not sure if you'd regard "easier , simpler", that's not point of rest. rest has been described roy fielding "software engineering on scale of decades", , point create interface allows relatively independent evolution of client , server implementations, crucial application operates @ web scale. there price pay this, client has interact server ti discover information needs progress interaction.

q2: not consider sensible mix rest , rpc in same api. (it might make perfect sense expose rest external; clients , use rpc internally, or offer separate apis.)

my rationale if have rest api, adding rpc element potentially creates tight coupling between client , server rather negates point of using rest in first place.