I have a django-tastypie project, where I've added nested resources to the schema. I'd like to add these endpoints to the top level schema, generated in api.top_level, but I don't see an easy way of doing this without re-writing the top_level method and hard coding the new endpoints.
Is there an easy way of adding nested resources to the top level schema, or is there a better way of doing this.
E.g. adding list-endpoint and schema fields for each nested endpoint in the parent schema.
Related
I have a requirement where the model schema will be generated by the user from a user interface that will be exposed by REST API that means dynamic models, controllers and repositories. This already has been achieved.
Now the requirement is to allow users to specify relations between tables from the same user interface. For e.g. I am creating a table order then while defining its properties I should be able to map product_id property to product table.
How can I achieve this?
I am afraid LoopBack 4 does not offer first-class support for building model relations dynamically yet. We have been discussing this feature in GitHub issue loopback-next#2483
Essentially, there are two parts of the problem:
Create repository artifacts for navigating to related models.
This is IMO the easier part, since all you need to do is take the class constructor created by defineCrudRepositoryClass for the model you are trying to expose via REST API and create a subclass that will call methods like createHasManyRepositoryFactoryFor and registerInclusionResolver from the constructor.
Define a controller class implementing relation-specific REST API endpoints.
This is slightly more involved as you need to implement function that will define a new controller class with dynamically generated OpenAPI metadata for each model relation you want to expose via REST API. I would start with copy and paste of defineCrudRestController function and then reworking individual endpoints to provide navigational API for your relation. You should probably create multiple define{relation}Controller functions, one for each relation type (e.g. defineHasManyController).
I think I am looking for as much advise as possible.
I have a project that I have inherited. The codebase is absolutely awful. I have a Django project, within this a React app. There's all manner of proxies between to fetch from the API to deliver up content.
However, I want to start to re-write the API, as it is awfully put together. Zero documentation.
To re-write the API, I would like take a copy of the exisiting database - and then work with this to write a more consistent API.
What would be your advise/steps/method to achieve this, and what should I look out for when doing this?
N.B. The database is PostgreSQL.
For this Django itself has the inspectdb command.
It will inspect all tables, fields, and foreign-key relations and then create unmanaged models for you. You can fix them manually with (perhaps) missing foreign-keys and then use them in django-rest-framework.
I'm working on some Django Rest Framework based project (quite expected API for some web-app). It has as traditional Django models, and some kind of model-like objects: they behave like Django models but don't store anything in DB. No tables, no content-types. When we ask them for objects, they goes to external API and forms resulting Queryset.
Now I need to build some role-based access system. To make the architecture clear and extensible, I want to make groups and permissions managable through the Django Admin interface. So, I guess, we need to put some permissions to DB and then we'll be able to add these permissions to user groups. After that, we'll check these permissions in DRF.permissions class. But since we have neither tables, nor content-types for these 'models', we can't add records to permissions table right now.
What is the right way to make this possible? Should I rebuild these 'models' through the metaclass with proxy = True? Or should I add a proxy layer above? Maybe I should add some dummy content-types by hand?
I have two models: Domain and Record. Many records link to a domain. The domains and records have their owners. I want to disallow users to create records in domains that they don't own. However they should be able to edit records if someone else (a superuser e.g.) created them and set owner to that specific user (even if they don't own a domain). This should work both for admin site and for API (rest_framework)
My question is - what is the simplest way to achieve this goal? Is there some django plugin that handles permissions for linking? Can I use model validators here (if so - how to distinguish if a new object is created)?
The problem here is that the Django Rest Framework and Django itself (via admin) are interacting only at the level of the models. In order to achieve your goal I would implement the following design:
Make the models aware of their owners and users. For that I would use django-audit-log.
Overwrite the default model Manager and build your logic in the create method, where I will query the user's attributes and throw appropriate exceptions.
Such a design shifts some of the business logic from the controller to the data model - there are some debates out there about the benefits and pitfalls of such an approach. But with the underlined constraints (Django admin and API) is the only common place where you could put it.
Is this what you are aiming for ?
I know how mythz generally feels about HATEOAS, but let's say that I have to follow the HATEOAS principles in my REST services and add links ("self", "parent", and other possible relations) to my DTOs.
Links like "self" and "parent" contains paths to the resources and those paths are of course related to my routes.
I'm using the following project/deployment structure for my ServiceStack REST service. If that matters, I'm using ServiceStack 3.9.71.
Service Gateway Assembly:
defines my DTOs. Each DTO has a factory creating that DTO from the corresponding domain object
defines operations and their routes
Service Implementation Assembly:
uses ServiceGateway to get DTO definitions and access their factories
does whatever domain logic requires and create the corresponding DTOs through the afore mentioned factories
Service Interface Assembly:
define my REST services and
calls ServiceImplementation from ServiceStack's HttpHandler, according to REST verbs (GET, POST, ...)
WHERE would be the proper place to add link information to my DTOs?
Option1:
In my Service Gateway, when I build the DTOs themselves. It seems logical:
I know what I need to know about my domain objects and I can easily
build the links. Except that my DTOs are now all including an
additional member (Links) and building those links forces me to
explicitly provide paths/routes (i.e. hard code them). Seems to lead
to a maintenance nightmare.
Option2:
In my Service Interface assembly, where I have the request context and
I know my routes. I can encapsulate whatever my Service Implementation
returns in a meta-object containing the response and a link
collection. However, to build that link collection, I sometimes need
information available at the domain (i.e. Service Implementation)
level. The big "con" side for me is that it creates a new additional
and artificial level in all my responses. Could be seen as a way to
standardize response formats but I don't like it.
Option3:
My hope is that I can write a wrapper generically "injecting" a "Links" member to all the DTOs
I return by hooking somewhere into ServiceStack in my Service Interface assembly. I haven't
investigated much in that direction because I feel I could be wrong on
the whole approach here.
Any advise / suggestion welcome. Thanks to all.
I'm not sure If I'm suggesting you option1 or option3, but this Is what I came out after trying to do the same thing.
I started from this answer.
Now you can access route metadata directly from filters.
So my current approach is:
=> Services create the dto responses and the next collection of hypermedia links that will be attached to the response. In this level you know the "operations" by type but not "how" you will build the routes. I think it is coherent that domain level deals with workflows of operations.
=> Within a response filter I get the available routes from Metadata, and build the routes from dto properties by convention. Finally routes are added to http header.
Caveats:
I'm mapping 1 dto - 1 route. This approach could be more difficult in other cases.