I am working with an existing web api. I upload a list of JSONObjectA to the server this then returns a list of JSONObjectB. This all works fine and I am happy with that. A problem arises when I send a list of 1 to the server. Instead of a List of one being returned, I only receive JSONObjectB. This means I need different Serializers to parse the data.
Would it make more sense for the server to always return a list (ie. always the same object) or would it be considered good practice to do it the current way?
It would make more sense to always return a list. When building an API you should always go for ease of use, and having 2 different types returned means that the API user has to do additional work that they shouldn't need to.
Related
I'm making a website that gets its info from a RESTapi I've written and hosted myself, have had no data problems thus far.
Now I'm trying a simple retrieve of a json object and I get all the info correctly as shown here in the API. (Visualized & tested in Swagger)
As you can clearly see, it retrieves it the complete object and underlying objects correctly (blurred sensitive info).
Pay attention to the property "AmountOfEggs" though.
Now when i call this api endpoint (exactly the same way) in my site and console.log the result.data, this is the feedback.
Now for some reason I can't recieve AmountOfEggs in my frontend.
I've recreated the entire object, wrote different names, passed different props (Id, NumberBus, etc are passed in this situation with no problem, which are also int (number) types).
I have no idea why this property gets "dropped" in the transfer and filled with/defaults to an empty string.
Any help would be greatly appreciated.
I found where it went wrong and it's due to different factors.
To start, I am making this site using the Vue framework, which has reactive components, which means, data gets adjusted and you get live updated components on your views/pages.
In the page that contained the call, I also wanted to add dynamic styling. The code I used for this is the following:
v-for="seller in retrievedSellers"
:key="seller.Id"
:class="[
'sellerStyle'
, (seller.AmountOfEggs = 0 ? 'grey-out-seller' : ''),
]"
Now two things to note, first of all this might look like backend coding but this is Vue logic on the .vue file which handles the dynamic options that Vue provides so I never thought to look here for the error.
The error of couse is the 'seller.AmountOfEggs = 0' part, using one equal sign (assignment) instead of two (comparison).
So I learned,
Vue doesn't throw errors on assignments in code that is used to generate frontend (where you should NEVER alter your data).
My console.log was the moment the response of the API came in, where apparently it was already assigned a new value (due to my code above) before hitting the console.log.
It still greatly surprises me that Vue handles ^this^ first to make sure your reactive components are up to date before finishing the api call itself.
However, I still don't understand how it said "" instead of 0.
I'm using typescript (javascript strongly-typed) so it definitely wants to contain a number and not an empty string. Even in the declaration of my DTO the property is defined as (and expects) a number.
I have a doubt. When is a GET request sent. I mean, I have seen a lot of people using if request.method == 'GET', when they render the form for the first time, but when the form is submitted, they do a `POST' request.
While they explicitly mention when defining the form in html that the method will be 'POST', they don't do the same for 'GET' request which is made when an empty form is requested.
How does django know it's a GET request?
And, why is it done so?
Thanks,
I'm not an expert but I think Django "knows" this because like all things on the Internet it uses the HTTP protocol. There are several HTTP methods. If not specified the default method will always be GET
GET
A GET is usually used to retrieve information. Typically a GET function has no side-effects (this means that data in the database is not changed, that no files in the filesystem are modified, etc.).
Strictly speaking this is not always true, since some webservers log requests (themselves) and thus add an entry to the database that a specific user visited a specific page at a specific timestamp, etc.
A typical GET request is idempotent. This means that there is no difference between doing a query one time, or multiple times (two times, three times, five times, thousand times).
GET queries are therefore typically used to provide static content, as well as pages that contain data about one or more entries, search queries, etc.
POST
POST on the other hand typically ships with data (in the POST parameters), and usually the idea is that something is done with this data that creates a change in the persistent structures of the webserver. For example creating a new entry in some table, or updating the table with the values that are provided. Since these operations are not always idempotent, it can be dangerous if the user refreshes the page in the browser (since that could for example create two orders, instead of the single order the user actually wanted to create).
Therefore in Django a POST request will typically result in some changes to the database, and a redirect as result. This means that the user will typically obtain a new address, and perform a GET request on that page (and that GET is idempotent, hence it will not construct a new order).
PUT, PATCH and DELETE
Besides the popular GET and POST, there are other typical requests a client can make to a webserver. For example PUT, PATCH and DELETE.
PUT
PUT is the twin of a POST request. The main difference is that the URI it hits, specifies what entry to construct or update. PUT is usually an idempotent operation.
This means that if we would for example perform a POST server.com/blog/create to create a blog, PUT will typically look like PUT server.com/blog/123/. So we specify the id in advance. In case the object does not yet exists, a webserver will typically construct one. In case the entity already exists, a new entity will typically be constructed for that URI. So performing the same PUT operation twice, should have no effect.
Note that in case of a PUT request, typically one should specify all fields. The fields that are not specified will typically be filled in with default values (in case such values exist). We thus do not really "update" the entity: we destroy the old entity and create a new one in case that entity already exists.
PATCH
PATCH is a variant of PUT that updates the entity, instead of creating a new one. The fields that are thus missing in a PATCH request, typically remain the same as the values in the "old" entity so to speak.
DELETE
Like the name already suggests, if we perform a DELETE server.com/blog/123/ request, then we will typically remove the corresponding element.
Some servers do not immediately remove the corresponding element. You can see it as scheduling the object for deletion, so sometimes the object is later removed. The DELETE request, thus typically means that you signal the server to eventually remove the entity.
Actually Django is based on HTTP responses-requests. HTTP is fully textuall. So Django parses each request and finds in its header information about what kind of request is it. I may be mistaken in details, but as I understand when server receives request - Django creates it's object request, which contains all the data from HTTP. And then you decide if you need a specific action on GET or POST and you check the type of request with request.method.
P.S. And yes, by default each request is GET.
I’m in the middle of making an Express app. It’s just a learning project.
I’m getting some info from an Anime api called jikan.me, it provides info about different Anime series like a picture url and synopsis.
For example one is at https://api.jikan.me/anime/16 .
Now, the jikan api might have a json endpoint at anime/1 but there's nothing at anime/2.
I want to find a list of all the numbers (https://api.jikan.me/anime/[numbers]) that actually contain endpoints.
I've tried simply going to https://api.jikan.me/anime but it returns error: No ID/Path Given.
I'm expecting there is likely no absolute answer to this problem but that I might learn something about server-side code along the way.
Where would I begin to look to find this info?
This is a bit late but, Jikan is an unofficial REST API for MyAnimeList. The IDs are respective to the IDs on MAL. For example; https://myanimelist.net/anime/1 can be parsed through https://api.jikan.moe/anime/1 but the ID 2 does not exist on MAL. It's a 404, hence that error.
To initially get some IDs, you can try the search endpoint.
Furthermore, I'll be releasing REST 2.2 quite soon (this month) which will give you the ability to parse from pages like these and thus you'll get another endpoint that provides a handful of IDs to get their data from.
Source: I'm the developer of Jikan
If it's not in the documentation it's probably information not available to you... a REST api needs to be specifically configured to offer certain endpoints, that number at the end might just be an ID that's searched for in an internal database and there's no way for the application to know if there's gonna be something there; all they can do is return an error message for you to handle as is the case here.
A REST API can have arguments in several places:
In the request body - As part of a json body, or other MIME type
In the query string - e.g. /api/resource?p1=v1&p2=v2
As part of the URL-path - e.g. /api/resource/v1/v2
What are the best practices and considerations of choosing between 1 and 2 above?
2 vs 3 is covered here.
What are the best practices and considerations of choosing between 1
and 2 above?
Usually the content body is used for the data that is to be uploaded/downloaded to/from the server and the query parameters are used to specify the exact data requested. For example when you upload a file you specify the name, mime type, etc. in the body but when you fetch list of files you can use the query parameters to filter the list by some property of the files. In general, the query parameters are property of the query not the data.
Of course this is not a strict rule - you can implement it in whatever way you find more appropriate/working for you.
You might also want to check the wikipedia article about query string, especially the first two paragraphs.
I'll assume you are talking about POST/PUT requests. Semantically the request body should contain the data you are posting or patching.
The query string, as part of the URL (a URI), it's there to identify which resource you are posting or patching.
You asked for a best practices, following semantics are mine. Of course using your rules of thumb should work, specially if the web framework you use abstract this into parameters.
You most know:
Some web servers have limits on the length of the URI.
You can send parameters inside the request body with CURL.
Where you send the data shouldn't have effect on debugging.
The following are my rules of thumb...
When to use the body:
When the arguments don't have a flat key:value structure
If the values are not human readable, such as serialized binary data
When you have a very large number of arguments
When to use the query string:
When the arguments are such that you want to see them while debugging
When you want to be able to call them manually while developing the code e.g. with curl
When arguments are common across many web services
When you're already sending a different content-type such as application/octet-stream
Notice you can mix and match - put the the common ones, the ones that should be debugable in the query string, and throw all the rest in the json.
The reasoning I've always used is that because POST, PUT, and PATCH presumably have payloads containing information that customers might consider proprietary, the best practice is to put all payloads for those methods in the request body, and not in the URL parms, because it's very likely that somewhere, somehow, URL text is being logged by your web server and you don't want customer data getting splattered as plain text into your log filesystem.
That potential exposure via the URL isn't an issue for GET or DELETE or any of the other REST operations.
I'm getting confused on a few things in regards to wcf rest.
If you call a login method, should I use a POST or GET? After implementing a POST, I started to find various articles saying you should only use post to update data, and get for retrieving data. Which is the most appropriate method?
If I had to change the Login method from a Post to a Get, how would I call this?
http://....myservice.svc/login/{username}/{passpord} or is there another way to call this?
Note that in my post method, I'm passing and returning data in json format.
I need to create a search function that requires to pass various parameters i.e. list, string, list, etc... I assume in this instance I would have to define GET method, but again how to I pass these list of objects? Convert them to json first and pass them as parameters?
A brief url sample would be great.
Ok, I guess I'll answer my own question based on further finding when researching it and remember that my answer is based on using JSON as parameters. I'm not sure how it would behave if xml was used as I did not try it.
It appears to make more sense to use POST when logging in as you do not want to display the information you are posting via a url. You could encrypt the data and pass it in the url using a GET method... Again I could be wrong, but that's how I interpreted the various articles I read.
Again, in this instance, it appears POST is the best solution if a) you require a large amount of data to be passed to your url and b) if you do not want to show this data to the user. If your query only requires simple parameters (i.e. userid, type, etc...) and you don't mind showing this info, you can use the GET method.
If you require to pass multiple parameters to a function, you should instead pass a single parameter. This parameter should be a single object. This object should be made of all the parameters you wanted to use in the first place, this way, when using the POST method, this object can easily be converted to JSON and it will handle passing multiple parameters through a single object and it will handle numeric, string, list<>, array<>, etc... very nicely.