Comments (8)
I didn't know GET supported JSON payloads.
E: at least not semantically
E2: of course any private information would be using a different request method (such as POST) and as such would be accepting a JSON payload in the request body, we would never do this via URL
from xenfororesourcemanagerapi.
Sorry what? I don't understand what you're getting at. GET is a standard part of REST....
from xenfororesourcemanagerapi.
@md-5 of course, it is a standard Request Word of HTTP. The current API version requires to add parameters as part of the URI though instead of sending them in the request body as a JSON-object. This is considered best practice because of reasons mentioned in the issue.
from xenfororesourcemanagerapi.
GET doesn't have a request body, I have no idea what you're on about
https://stackoverflow.com/questions/978061/http-get-with-request-body
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/GET
from xenfororesourcemanagerapi.
Having no semantics does not mean it is impossible, but it means that some services may have done the wrong thing in the past. As the Answer on Stack Overflow shows very good, the first RFC said you don't need a body, some developers read it as they can't have bodies, which was revised in the latest RFC 7231:
A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
That's why you can and should use a GET body. If you use nginx or Apache2 or IIS in the latest versions, you can handle them and most common languages like java or Python3 can handle them, too. The only usecase where this could be satisfying not to use is if a person would like to use the API in their browsers. However, that's what the website is for.
from xenfororesourcemanagerapi.
@dorsax Can you provide some literature supporting the claim that when using the standard GET request method that we should be using request bodies (which have no semantic meaning to GET) over GET parameters (the known standard)?
If you can provide these, we can have a more productive discussion. As of right now, all I am able to ascertain is that this is a style suggestion and not an actual nod to a new standard (please correct me if this isn't right).
A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
Sorry, but this doesn't do it for me. The first clause says there are no semantics, and the second clause supports the first by saying that sending a request body may cause the service to reject the request.
They'd reject the request because the request was not following the semantic definition of GET (which is that request bodies have no semantic meaning to GET). That makes sense to me. It does not seem to suggest that we should be moving toward handling request bodies while using GET.
As previously mentioned, we will (without question) use request bodies and proper standards while handling any private information. That said, however, for API keys there are numerous examples in the real world of those being accepted via URI. However, more likely, we will require it as an HTTP header. This would not go into the request body. Any other parameters are for reading only, and do not/would not represent any private information so we would be using GET + Header.
Like I said, get back to me if you wish to continue discussing this. I'm open to hear your side, but I'm not convinced at the moment.
from xenfororesourcemanagerapi.
Hey @simpleauthority
I had a deep dig into my past projects where I called different REST APIs to get a better personal overview because I started to doubt myself. In my "study" I got the following results:
- any API w/o authentication uses GET with URI parameters
- any API with authentication uses POST request with JSON bodies
- mixed APIs apply the URI parameters in GET, POST uses JSON body
I have to admit I was biased from the beginning and I know now why. First, the latest project I am working on uses a closed source API (documentation isn't publicly available, too), where even GET uses a request body. Second, almost any APIs I used in the past year had authentication, and I almost exclusively worked with those parts. It seems like I assumed that a Request Body was the de facto standard because of this bias.
I also want to admit that I came here with the authentication part in mind and didn't explicitly wanted GET with a request body. I just assumed it was a standard, which I have now proved myself to be wrong. Somehow I was triggered after the first message of @md-5 because it wasn't very constructive but rather destructive to me. I want to apology for the mess. Thank you for your work on an API, all devs can benefit from that :)
from xenfororesourcemanagerapi.
None of the apis in this project have authentication....
from xenfororesourcemanagerapi.
Related Issues (20)
- Add ability to specify sorting mode for resource listing HOT 2
- Improve documentation HOT 9
- Send 404 when the resource or author is not found HOT 6
- Little error on README.md
- [Suggestion] Expose Resource Version in `getResourceUpdate` Response HOT 3
- Wrong default icon HOT 2
- `native_minecraft_version` and `supported_minecraft_versions` return null. HOT 6
- List number of resources & resources per page in API response HOT 1
- Premium Verifier HOT 3
- Get information to members (getMemberById) HOT 7
- Endpoints for authenticating an application with user credentials HOT 8
- Lower the cache TTL for author-related endpoints HOT 6
- `listResources` endpoint category parameter issues HOT 3
- Include category in endpoints returning resource information
- Suggestion: improvements to getResourceUpdate HOT 3
- The paginated pages in the api are in reverse order to spigot pages HOT 3
- API returning wrong resurces? HOT 4
- Add a way of searching SpigotMC resources HOT 2
- Post Resource Updates
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from xenfororesourcemanagerapi.