I am new to Django and API creation. I am trying to figure out if it is better to use djangorestframework or just use JsonResponse. I got the suggestion of djangorestframework from Digital Ocean's tutorial but also found out about JsonResponse, which seems simpler given that I don't have to install another package.
Goal: I would like to be able to provide user information for both web and mobile applications.
I see that there are some reasons provided on this post for djangorestframework, which I pasted below for posteriority.
The common cases for using DRF are:
1)You're creating a public-facing external API for third-party
developers to access the data in your site, and you want to output
JSON they can use in their apps rather than HTML.
2)You're doing mobile development and you want your mobile app to make
GET/PUT/POST requests to a Django backend, and then have your backend
output data (usually as JSON) to the mobile app. Since you don't want
to pass back HTML to the mobile app, you use DRF to effectively create
a REST API that your mobile app can call.
3)You're creating a web app, but you don't want to use the Django
templating language. Instead you want to use the Django ORM but output
everything as JSON and have your frontend created by a JavaScript MVC
framework such as React, Backbone, AngularJS, etc. In those cases, you
can use DRF to output JSON that the JavaScript framework can process.
DRF basically provides you many features to make APIs that you don't have in raw django.
for example:
Serializers: a declarative way(django style like declaring models) of making serializers, when you use JsonResponse you have to tell everywhere what to serialize, with the serializer you have to import it and just use it, also this serializers can be able to save/update objects too. Also support ORM source to connect yours models(think how difficult would be serialize a model with nested relations with JsonResponse).
The Web browsable API, you can see all the availables endpoints.
Third party packages to install and use: https://www.django-rest-framework.org/community/third-party-packages/#existing-third-party-packages.
I recently started learning to create restful web services with spring framework.
all the course is using postman to send requests but I want to send requests from a web page, like creating a table and send firstName and lastName from the HTML file (from the view, .jsp file) and store it in the database.
everywhere I lookt, they all saying the standard file to send to or retrieve from a restful endpoint is JSON, not HTML.
and from what I see #RequestBody only accepts JSON or XML, not HTML inputs.
I tried sending data from HTML(Method = "POST") to a #PostMapping method of my restful web server, to create something and store it in the database but an exception that says "Content-type not supported" was thrown.
I have lots of questions about this, and they all point to the same thing, Not understanding the whole thing.
what's the point of creating restful web service for the back end of a website, when HTML doesn't support put and delete requests and standard file that everyone uses to get requests from the client is JSON, not HTML.
can a web page (HTML) generate it's content to form a JSON file that is being sent back from a restful server?
how can I generate a JSON file from the inputs in HTML file and send it to the restful #PostMapping method?
there are two things that I should mention here,
I don't know much about creating web pages (HTML) I have only been creating very simple HTML files to help me create and test a back end server.
I searched so many questions before I post this one, and none of them helped me.
I will try to answer your questions
First, you need to understand what rest is it is a Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services.(https://en.wikipedia.org/wiki/Representational_state_transfer)
so we follow a set of standards to make things easier.
Now coming to your actual question why JSON and not HTML because these are not only consumed from HTML these are consumed by different apps or services and json is a more lightweight and less verbose format, and it’s easier to read and write as well. In most cases, it’s ideal for data interchange over the internet
and we can use it with front end libraries like react , jquery or vanilla javascript to render the content in HTML from JSON without any changes to the API and also use a Backend web service to use this API.
https://api.jquery.com/jQuery.getJSON/
https://reactjs.org/docs/faq-ajax.html
for the other two questions basically You don't have to generate JSON file to call the rest API from HTML and render the content in HTML Instead you can use front end libraries like Jquery, React, Angular or use vanilla javascript to render content and call the rest API.
I want to render a UI from a jSON string that has multiple layers.
The user should be able to enter data, which will then be stored and shared, without the overhead of the jSON Render Structure.
However, the assignment of the data must be possible.
The app renders a template from a multidimensional json string that can capture metrics (user inputs). The measured data are entered via text fields by the user.
There are different windows in the app, which are rendered from different json UI-render-files.
The stored algorithms in the windows at the Frontend differ.
The following should be possible:
All windows are created with different jSON strings (works with build_value now).
The user's input is saved. (Currently only works by saving the render json string with the data under a different name (with Package: Shared Preferences)).
The data entered by the user is copied from one window to the other window. (Data Binding / Data Mapping)
The data entered by the user will be sent to a backend.
I only have the idea to use id's in the render json, which allow a mapping.
Are there better solutions?
Saving the entered data is possible by saving the whole jSON - String with an other name.
The goal is to map the data.
It should also be possible for the user to insert another object for the measurement data acquisition at the client / device. The entered data must also be saved.
This sounds like a REST API. Then you would use a frontend framework like angular or react to take user input.
I could build this with a .net core web api with sql db as the backend. this would be a web service (REST API solution) on the backend of your solution.
Next I would integrate Swagger with dependency injection and add authentication.
now its time to create the front end that will use your tested Web Service.
you would have 1 side of your SPA POST new JSON to the Web service in a form.
you would have the other side GET the new record as a new tab with pagination or in a table with pagination.
This would be a good PoC for your idea and will let you learn the parts of the solutions architecture in your language of choice. the "design" would be the same no matter what language your choice.
backend web service can be done in a flask and with a MySQL DB. or with any other combo you have skills with.
the Frontend could be done in knockout.js, making it a little easier to learn than angular or react.
Please create new questions when you choose your software design. I would love to give answers for each:)
I would love to level up with you! ;)
I have a use case where I want to implement custom search functionality for a Shopify site. So instead of using getting a JSON with Ajax and making a html and replacing the html. Is there a way where I can override the search.results data that the .liquid files are using.
So when I make a search in /search?q=xyz, I want to get the data from my API, and use that data to render the product-item.liquid. This way I don't have to worry about the UI of the product-item for different themes.
Yes. You can easily do this. You would install an App in your shop, and create an endpoint you would call with your search criteria. The end point is handled by a Shopify App Proxy, that securely allows you to callback the App. You could return Liquid as results, or just JSON as you wish. It is a standard and simple pattern for you to use.
See here: https://help.shopify.com/api/tutorials/application-proxies
Let's assume an web application that for each URI presents a nice html view for GET requests and allows to update the underlying resource through POST/PUT/PATCH/WHATEVER.
How do I then expose various forms that actually allow performing such requests from the browser? And broader: assuming I have alternative views (possibly also HTML) for the same resource, where do I put those? Arguably, such forms can be considered alternative views, so having an answer to the broader question would be ideal.
Edit: To clarify, my question is not about pure data APIs serving JSON or whatnot, but about HTML apps such as Stackoverflow. For example you can get the collection of questions under /questions and this particular one at /questions/24696982 which makes sense. To get the form to add a new question, you will have to use /questions/ask, which I'm not sure is alright. And that form POSTs to /questions/ask/submit, which seems just plain wrong. Making a GET request to that URL yields a 404 (if anything it should be a 405). The form should be POSTing to /questions. Still I would like to know whether at least the URI for the form is considered acceptable in a RESTful system.
You have a website like, the one way to build a real RESTFull API is to split the frontend and the API - thats in my opinion the best way (some may disagree) - maybe some other don't think like this but lets say the frontend team got www.domain and your team for the API got api.domain.
GET api.domain/questions - Retrieves a list of tickets
GET api.domain/questions/12 - Retrieves a specific ticket
POST api.domain/questions - Creates a new ticket
PUT api.domain/questions/12 - Updates ticket #12
DELETE api.domain/questions/12 - Deletes ticket #12
PATCH api.domain/questions/12 - Partially updates ticket #12 #I only want to display that this also exists - i don't really use it...
AWESOME EDIT: As you can see also stackoverflow uses this method: api.stackexchange.com
So as you can see you can have these structure - but you also can have a form on www.domain/questions/ask and this form would send the request to api.domain/questions via POST. I want to refer to: https://thenewcircle.com/s/post/1221/designing_a_beautiful_rest_json_api_video its a really nice podcast you should have heard.
EDIT: (another point of view)
Another idea is that you can simply choose which content should come back (Json,XML,HTML) if your client sends you the right Accept-Header.
Example 1:
URL REQUEST ACCEPT HEADER RESPONSE
-----------------------------------------------------------------------------------------
domain/questions GET application/json all questions as json
domain/questions GET text/html the page as html with all questions
domain/questions/ask GET text/html Your html for to add a new question
domain/questions POST application/json Add a new new questions (this would be called from ./ask to add the new questions
domain/questions/ask GET application/json 404 Status-Code because on questions/ask you don't have implemented any resource
Example-2:
URL REQUEST ACCEPT HEADER RESPONSE
-----------------------------------------------------------------------------------------
domain/questions/12 GET application/json Shows the questions with the ID 12 as JSON
domain/questions/12 GET text/html Shows the HTML representation of your page
domain/questions/12/edit GET text/html Your html for to edit a the question
domain/questions/12 PUT application/json Updates the questions with the ID 12 // just to add the PATCH thing.. i don't really use it but if you don't update the whole object you could/should use PATCH instead of PUT :p
domain/questions/12/edit GET application/json 404 Status-Code because on questions/ask you don't have implemented any resource
Yesterday I told you about the first idea (which is - I think for using an api as a team (one for frontend and one team that develops the api - a better way) but as #jackweirdy commented (thanks for that - i then searched a lot and was looking at other podcasts from developer around the world and how they would do that) below it's really all up to you - it's your api and at the end you/your team will decide for one way. Hope this helps you or other that looking for how to build a API on a REST background.
The examples in the EDIT-Section would be (if I got it right) not like here on stackoverflow
This is something I've had trouble with myself, and which I don't think there's a right answer to.
Assuming I have an API exposing /people/:id, I generally reserve an endpoint for /people/new. a GET request to that url with Accept: text/html will return a form for creation, but anything else will throw a 404, since this page only exists for people in a web browser. The form on that page will then post to /people/ as you'd expect.
Similarly, if someone wants to edit an existing person, the form to do that might be served from /people/1/update, again HTML only.
If your API has that structure, then I think reserving keywords such as new or update is perfectly reasonable.
As far as I can understand your question, you want an application that :
displays HTML pages (and eventually other formats ?)
displays form views for creation of new elements or for update of existing ones
accept POST/PUT with url encoded data (sent by submitting above forms) to create of update those elements (and eventually other formats ?)
Ruby on Rails is a framework that is targetted as this kind of requirement. Extract from the guide Rails Routing from the Outside In :
HTTP Verb Path action used for
GET /photos index display a list of all photos
GET /photos/new new return an HTML form for creating a new photo
POST /photos create create a new photo
GET /photos/:id show display a specific photo
GET /photos/:id/edit edit return an HTML form for editing a photo
PUT /photos/:id update update a specific photo
DELETE /photos/:id destroy delete a specific photo
You can have HTML views for the actions index, new, show and edit.
Personally, I would recommend to add the following :
POST /photos/:id update update a specific photo
POST /photos/:id/delete destroy delete a specific photo
so that it would be simpler to update or delete elements via html forms.
All those paths are only Rails convention and are not imposed by REST but it gives a clean example of what can be done.
But it is quite easy to make an application following the same or slightly different conventions using other frameworks. Java + Spring MVC can do that very easily, with HTML views using JSP, Velocity, Thymeleaf or others, and the possibility of using JSON in input or output simply using HTTP headers or suffixes in URL (GET /photos/:id.json) with a little less magic but more control than RoR. And I'm not an expert in other framework like Struts2 (still Java), or Django (Python) but I am pretty sure that it is possible too.
What is important :
choose a language (Ruby, Python, Java, PHP, ASP.NET, ...)
choose a framework compatible with RESTfull urls
ensure you can have views in HTML, or JSON, or enter the format you want by adding a suffix or a HTTP header and eventually the appropriate adapter/converter
You could do it by hand but frameworks limits boiler plate code.
The essence of REst was never about how URLs looks like,but how http verbs and headers are used to transfer datas.
This whole "restfull urls" thing is made up by people who dont understand what Rest is. All the Rest spec says is that URLs must be unique.
Now if you really want "restfull" forms,then form should be a resource with an id, like /form/2929929 .Of course it doesnt make sense to do so,since forms are strictly for web users and REst doesnt care about how data is acquiered, only about how it is transfered.
In short,choose whatever URL you want. Some frameworks use new and update for forms. By the way the /questions/ask/submit is totally valid in a Rest context, because what you submit and a question can be 2 totally difference resources.
You need to understand that there is a difference between a RESTfull application and a REST client.
A RESTfull application has pure restfull urls as you described, such as
GET /persons : gets a list of all the persons in database
POST /persons : adds a new person
GET /person/1 : gets a person with id 1
PUT /person/1 : updates person with id 1
DELETE /person/1 : deletes person with id 1
and so on...
Such an application does not have any forms or UI for submitting data. It only accepts data via HTTP requests. To use such an application you can send and receive data using tools like curl or even your browser, which allow you to make HTTP requests.
Now, clearly such an application is not usable from the user point of view. Hence we need to create client applications which consume these restfull applications. These clients are not restfull at all and have urls like:
GET /person/showall : displays a list of all persons
GET /person/create : shows new person form
POST /person/create : submits the data to the restfull application via ajax or simillar technology.
and so on...
These clients can be another HTML application, an android application, an iOS application, etc.
What you are trying to do here is create a single application which has both restful urls for objects as well as forms/pages for data display and input. This is absolutely fine.
Just make sure that you design proper restfull urls for your objects while you can have any url you find suitable for your forms.
In 100% RESTful Web services resources are identified using descriptive URLs, that is URLs composed only of noun phrases.
Generaly speaking, for creating a new resource, you would use PUT, although some frameworks (such as Zend Framework 2, if I remember well), use POST for this purpose. So, for creating a question you could PUT questions, then providing the question identifier in the body of the request, or PUT questions/{identifier}, thus providing the id in the URL.
Contemporary web/cloud applications have moved to what is known as a single page application architecture.
This architecture has a back end REST API (typically JSON based) which is then consumed by either single page applications or native client apps on mobile phones and tablet. The server is then much easier to implement and scale and provides the needed access regardless if its a web client or a native phone/tablet platform.
The client architecture is known as MV* for Model, View and * is anything else the framework provides such as controller logic and persistence.
In my applications I have used a number of MV* frameworks and libraries in anger and investigated many many more. I've had some success with backbone, and my favorite Ember.js, although there are many frameworks and everyone has their favorite for different reasons and that is a whole topic on its own. I will say that depending on the needs of your application different frameworks will be more or less appropriate. I know what matters to my productivity so I have settled on Ember after doing the rounds.
On the backend you have a similar myriad of choices but choose a platform that is known to be mature and stable ans same goes for your data persistence. There are a number of cloud services that give you a REST/JSON api with no coding or deployment concerns now so you can focus more on the client development and less on the server.
It is important to understand that in single page applications the browser url does not need to have a 1 to 1 correspondance with the backend rest api. In fact it would be detrimental to usability taking such a simple minded approach. Of all the client frameworks Ember gets this right as it has a built-in router, and as a result client state is captured in the URL so the page can survive a refresh and can also be bookmarked. You really can keep your client view independent to the backend api endpoints. I design my client URLs around the menu/structure of my forms. In complex apps the URLs nest as far as I need the app to partition and drill down into the details, yet the api endpoints are flat and may span multiple service providers. A view in my client app often assembles data from multiple endpoints and similarly on Accept/Save it pushes to multiple endpoints. It is also possible to implement local persistence so the web client can be used offline and so that temporary or half filled out forms can survive a page refresh.
Another consideration with such an architecture is SEO. With single page applications one needs to be able to provide prerendered pages to web crawlers. Fortunately there are a number of tools which can auto generate the pages for single page applications so that web crawlers can still index your sites content, tools such as pretender.io and many others can solve this for you.
At the end of all this you have a server with a number of REST endpoints and typically a single index.html, app.js app.css and any other assets such as images and fonts.
Typically you need a toolchain for generating these files from your source code which are then either hosted on your domain or on a CDN. I also configure my app and server for CORS so the web client can be hosted on a different domain to the REST back end which also works well in development.
I recommend the broccoli or ember-cli tool chain for assembling all your web client assets and I have also had good experience with Brunch. I've tried most of the tools out there and those are the only ones that get my vote.
For API design I've been actively providing feedback on the latest drafts of JSON API. There is a lot of good work being done there and you can use that as a good starting point.
Usually in production Web Applications I recommend separating how static content is delivered vs how dynamic content is delivered.
Let us hope you are not constrained by SEO and can actually use the wonder of DOM manipulation (ie Client-Side templating)...
I would highly recommend going down the path of learning how to create a SPA (Single Page Application)
However, back to the topic at hand.
Static content (HTML, CSS, Javascript, images) should be delivered thru a different server than your dynamic content (the REST data in json/xml format).
Your HTML should use JQuery/AngularJS/Backbone -- some type of JavaScript framework to actually "render" your HTML on the client-side using JavaScript.
The JavaScript frameworks will also make the proper RESTful calls to POST or PUT a form (which should be a UI representation of some REST path)
Lets say you have a form for a Profile,
GET /profile/{id} would be called to pre-populate a profile FORM
PUT /profile/{id} would be called to update the profile
** JavaScript will pre-populate the FORM by calling one or more RESTful GET methods.
** JavaScript will take entered data from FORM and POST/PUT it to the RESTful server.
The point you should take away from this is:
Let an advanced JavaScript library handle the sending of RESTful requests and "rendering" of the HTML.
HTML is only a template (static content) and can be hosted on a completely different server that is optimized for the job of delivering "static content" :)
Hope that makes sense.
Cheers!
P.S.
Learn about Cross-origin resource sharing (CORS) if you have not already. You will likely need that knowledge to properly host your static content on a different server/domain than your dynamic content.