I have just read Resource-Oriented Architecture: The Rest of REST. The reasoning behind content negotiation is compelling, but there's one thing I sometimes need, which seems to be impossible in this schema.
Let assume I've got a web service to deliver some graphs. I want users to choose between different styles of these graphs (a fancy color one, B&W, ...), but all of them are always png images. For all of them the mimetype will simply be image/png. So what is the preferred way to negotiate custom parameters?
Use querystring parameters.
Related
So I just created a website's front-end using ReactJS. Now all I need is a backend database that I will fetch data from using requests.
The question is whether I need to render templates using my backend or just use my server to make requests (eg get, post etc)
PS. I will be using Django as my backend.
Thank you everyone who will help me out.
Doing both is recommended. Based on the requirements and use cases we must use both ways to render.
For example, Some products use initial html as a Server side rendered page with all essential data required inserted as scripts and so on. This helps in loading primary content faster. If we are not following this in applications that require data initially. Then it might take more time to fetch React chunks, scripting and after seeing an API makes request, and then getting data and then displaying the primary content. So when a page needs more data (like More API calls) then server side rendering might be a good way.
For other scenarios like getting user details, All these can be done using React.
No, because you will use DRF (Django Rest Framework) to communicate between frontend and backend. Basically you will write your own APIs in the views.py that will respond with JSON data, at least in major of cases this will be enough. So, you don't need templates, since template are really Djangos' frontend, that you will not be using at all.
But, this heavily depends on what you are doing and what is your setup.
I have a REST API that I'd like to port to run as a collection of cloud functions. I'm wondering how to split up the different endpoints in the best way, and how much to rename endpoints to fit the GCF model.
For example, I have the following types of request.
GET /images
GET /images/<image_id>
POST /images
If this was implemented with GCF, these would all fall under the same function images, and then I would need to implement some routing based on HTTP method, plus a pattern match for <image_id>, etc..
I could however choose to implement something like...
GET /images
GET /image/<image_id>
POST /createImage
...so that each endpoint has a distinct function that is invoked. This seems more appropriate from a cloud functions point of view, but not at all appropriate from a RESTful design point of view.
What are the trade-offs for implementing cloud functions in one or the other of these ways?
ember-data understands json-api natively ,if we have to integrate ember-data and its save() and find() methods with postgrest style REST calls, where do we need to do changes ?
Do we need to modify client side in ember or some server side logic for mapping with ember-data requirements.
So postgrest REST api calls look like these to get films and their title and competition.name from related table ->
http://localhost:3001/film?select=title,competition{name}
http://localhost:3001/users?select=email::text&id=eq.2&sign_in_count=eq.16
There are two questions here:
Is it better to transform to/from JSON API at the server or the client?
If transforming in the client, where do transforms to/from JSON API occur?
Is it better to transform to/from JSON API at the server or the client?
The first question is really a matter of preference. I personally prefer having the server emit and accept JSON API format because it allows you to ship fewer lines of JavaScript to the client and there's a tendency for multiple clients to communicate with the same server, so standardizing that makes for faster client application development.
For example, you might have two Ember clients (one general user-facing, one admin-facing), an iOS client, and perhaps another server all requesting to your PostgREST server.
That said, you can also think of the format that PostgREST uses as its own spec and have all the clients adhere to that.
If transforming in the client, where do transforms to/from JSON API occur?
Which brings us to question 2: How do you make Ember Data communicate with a server that does not use the JSON API standard?
This occurs in two places: The Adapter and the Serializer.
The Adapter translates requests for data into the appropriate URL where the data can be found (or added) and initiates requests.
So, "give me the photo with the ID of 22" (store.find('photo', 2)), will ask the adapter (assuming Photo #2 isn't already loaded), "hey, someone wants Photo #2, go fetch it please".
The Adapter will make the request and hand the response over to its Serializer.
The Serializer is responsible for translating the data that comes back into a format that Ember Data understands: JSON API.
Both Adapter and Serializer have methods you can implement to customize their behaviors.
In your case with PostgREST, the best places to start would be implementing your own findRecord on the Adapter and implementing your own normalizeResponse on the Serializer.
The docs for both explain the actions you need to take and what type of value you should return from each method.
These are two of the most basic interfaces. They don't provide a lot of functionality out of the box, but will help you become familiar with how these two objects interact.
Once you're comfortable with this basic interaction, check out the sample RestAdapter and RestSerializer for ideas on how to rely on some of the conventions Adapters and Serializers have to offer to clean up any custom code you've written.
I am not able to comprehend what would be pros and cons of the following approaches in making a single page backbone application using RESTful APIs from Django Rest Framework.
Render the whole app from within Django's template.
Serve the backbone app from another server ie node server. With nginx in the front for both servers.
Serve the HTML/Templates and JS from a separate CDN.
What are the things to take care ie points of caution in each strategy. Is there any other way to tie them up which I am missing?
This is a very broad question, and really it has nothing to do with Django or Backbone. What you're really asking about is a "thick-client" architecture vs. a "thin-client" architecture. In other words, having your user interface rendered on the client vs. having it rendered on the server.
First, allow me to recap a few things to make sure we're on the same page. The "thin-client" approach is the traditional/old school model, and the model Django itself is based on. The server renders HTML, sends it to the client, and whenever the client wants to do something it sends data back to the server and asks for fresh HTML.
In contrast the more modern "thick-client" approach lets the client render all of the UI. Whenever the client needs to do something it makes an AJAX request to a (presumably REST-ful) API, powered by a library like Django REST Framework. That API just returns the relevant data, and leaves it up to the client to render it appropriately.
There are advantages and disadvantages to both approaches, but the thick-client approach is becoming more and more popular because:
network transactions are faster: because your server is only sending the exact JSON you need instead of a mess of HTML, the "payload" of the response is much smaller
you can fetch all data "behind the scenes"; this makes things appear faster to the user, and lets you implement UI paradigms (eg. infinite scroll) that a thin client can't
the client/server relationship is simpler, because the people writing server code never have to even think about HTML or any other presentation logic; they get to just focus on the data (which, being server engineers, is probably the part they're most interested in anyway)
This is why a lot of companies (including the one I work for) have all but abandoned Django proper in favor of API endpoints served by Django REST Framework.
So, if you want to go with a thick client architecture, Django should never serve anything except the very first HTML page (and even that could be served by ngnix if you wanted, since it's just static HTML). After that you'd use a Backbone.Router and Backbone.Views to render your site. Whenever you need new information from the server you'd fetch a Backbone.Model or Backbone.Collection (with its url property pointing to your Django REST Framework endpoint).
I can attest that this whole approach works great; the site I work on is very complex, with many endpoints, and Backbone + Django REST Framework handles it beautifully. The only (slightly) tricky part is caching: in the thin client approach the browser automatically caches pages for you, but since there are no "pages" in a thick client (just AJAX responses with data) there is no automatic caching. This means that if you want to cache data you'll need to do it yourself, for instance with a Backbone.Collection devoted to that purpose.
Hope that helps.
P.S. Back in the day Django REST Framework didn't handle Django authentication stuff (ie. logging in/out) quite the way we wanted, so we wound up serving one other page, our login page, from Django. However I'm pretty sure the current Django REST Framework handles authentication stuff much better now, so this likely won't be an issue for you.
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.