Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What's the RESTFul pattern for enabling and disabling a system user.
Example:
a DELETE request to /users/123
and PATCH/UPDATE request to /users/123
Or should I use /user/enable/123 using PUT and /user/disable/123 using DELETE?
First of all: DELETE always removes a resource. So it cannot be used to change a value. Read more about the different Http methods and how they are supposed to used here: https://www.rfc-editor.org/rfc/rfc7231
You can solve this in three different ways. Whatever fits you best.
Update user object
Another approach would be by updating the User resource.
In this case you could send a PUT /users/123 with a body that contains the full updated user object.
Partial update of user object
If you define that you are allowed to do partial updates (partial means you only need to send the changed values which will be merged in to the existing user object) you can send a PATCH /users/123 containing a json with {enabled:true}. This is usually a bit trickier to handle on the backend.
Directly set enabled property (not recommended)
enabled is a property of a User. There for you can address this property directly in your URL.
You can use PUT /users/123/enabled with a body that contains true or false. To this approach, also see #Roman Vottner comment below
What's the RESTFul pattern for enabling and disabling a system user.
How would you do it with pages on a web site?
It might be that you would load a page that describes the system user, and from there navigate to a form with affordances for changing the users state; you would set the values on the form you want, and submit the form to the URL provided. The server would process the request, and either give you a status page, or redirect you back to an updated copy of the user, or whatever.
Notice: throughout the entire process, the client is following links provided by the server; no guessing URI, no guessing which http methods to use; the client follows the instructions embedded in the hypermedia
Repeat that same process in a machine readable way, and you've got a REST api.
REST, keep in mind, is about manipulating "resources" by passing messages around; the changes made to your domain model are side effects of the resource manipulation. In other words, the resources are part of your integration domain. See Jim Webber - REST: DDD in the Large
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am trying to build a small REST API for one of our clients, who was wishing for that kind of API. It's the first time I read into that topic.
Most of our services take quite some time for fully processing client orders. For that the client may create resources by POSTing xml data and retrieve results (much) later by GETting the corresponding resource. That was pretty straight forward.
Now though we want to create another service, which will typically evaluate results almost immediately and I really don't know, how to implement it with best practice.
Since the request can be processed immediately I want to avoid using two requests for creating and retrieving the resource. It just seems unnecessary and laborious.
On the other hand one single fitting HTTP request method does not seem to exist for this problem since POST requests shouldn't respond with anything but a response-code and GET requests should be independent from their body (today it seems to be possible to send body data with GET requests, nevertheless it seems to be bad practice and should not influence the response. In other words the server is only allowed to use information, which is contained in the URL).
Further I cannot send the data as query parameter in the GET-URL since the data contains very sensitive information - we have pretty strict laws regarding that topic in my country and I learned to be very careful .
What would be best practice for implementing such kind of responsive tool.
Is the REST API maybe the wrong choice anyway?
Thanks
POST requests shouldn't respond with anything but a response-code
This is not quite right.
In case of a POST that resulted in a creation, you should use a HTTP 201 status code and include a Location header that points to the URL of the new resource.
In addition, POST response may contain body with representation of the created object: 'Best' practice for restful POST response.
So the method POST is what you are looking for. It creates new resource and returns the representation of newly created object in the body.
If your service will modify objects after creation, it's up to you how to deal with it. If time of modification is very short, you can wait until object is modified and then return the object ready to use. Otherwise, you can return object with incomplete fields. Both approaches are RESTful.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I am really new to REST and that kinda stuff.
I want to create a small service (using Java Spring - also new to me), which should resize an image in a few different ways. Currently, I have 0 clue on which REST command I should use for this.
This is how I imagined my API to work:
I send a request containing the following information:
Original image (from client)
new width + new height
sizing strategy (nearest neighbor ...)
Server returns the new resized image
I am having trouble understanding which REST command I should use (all the information I could find was regarding storing data on the server).
I don't want to store any images or return any stored images. I just want to manipulate the image from the request and return it.
If you need more information, let me know.
I don't want to store any images or return any stored images. I just want to manipulate the image from the request and return it.
HTTP doesn't have a great answer for this today.
HTTP is an application protocol, whose application domain is the transfer of documents over a network -- Webber, 2011
The semantics of an HTTP Server are very closely analogous to those of a document store - we ask for copies of documents (GET), or we ask that a server's copy of a document be edited (POST,PUT,PATCH,DELETE....).
Of the registered HTTP methods, there isn't a good fit for an effectively read only request with a payload.
Which leaves you with one of the following options
You can use a standard method in a non standard way, and accept responsibility for the consequences
You can use a non standard method
You can define a new method, and register it, working through the standardization process and driving adoption
You can use POST.
POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.” -- Fielding, 2009
I am having trouble understanding how I can put an image and other information in a single payload (maybe as bytes?)
Consider how you might achieve that on the world wide web.
You would probably have an HTML form, with an input control (type="file") that allows the operator to specify which file to use, and additional input controls that collect other information of interest. The description of the form might include default values pre-loaded into the input controls, or lists of options, and so on. When the user submits the form, the web browser's implementation of standardized HTML form processing is applied to the inputs, producing an HTTP POST request with content-type multipart/form-data.
It's very similar in appearance to an email with one or more attachments.
At the origin server, the payload is unpacked - in effect reversing the transformation of the form inputs to their separated representations.
The downside of POST, in this context, is that it doesn't communicate to general purpose components the fact that your handling of this request will be idempotent. So we don't get "automatically retry the request" when the network is losing messages.
Furthermore, general purpose components are not going to be able to usefully cache the response, because they don't have a standardized method for including the request payload as part of the cache key.
In short, POST is the best you can do with standardized methods.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have read several sources about HTTP methods, but I still don't understand clearly the simplest thing: what are they for?
Each source I've seen points out when particular methods should be used, but what does it change in practice? Is there any difference how the request is being handled between, let's say, GET and POST?
Or maybe those methods are there to allow us to handle multiple behaviors on one URL?
And finally, what about the browsers? Forms can only make GET and POST requests and they handle them in different way. POST form sends data "in the background", while GET passes them in the URL. Does it have anything to do with the protocol or is it just browsers' convention?
Thank you in advance for clarifying it for me. :)
Fundamentally, yes, methods are there to allow different "interactions" with every "entity". HTTP is designed so you can think of each URL as one entity.
/users represents all users
/users/dave represents one specific user
POST /users lets you create a new user
PUT /users/dave lets you modify a specific user
GET /users gets you a list of users
GET /users?name=dave lets you query for a list of users named "dave"
and so on...
That's the way HTTP was designed to be used, each verb has a specific implied meaning. You can use those verbs any way you want really, but GET implies "passive" information retrieval, while POST, PUT and DELETE imply destructive changes.
Browsers and other clients do handle these differently. It's expected that anything GET can be requested at any time any number of times, can be cached, can be pre-fetched, can be queried mostly out of order. More destructive actions should be performed only once when requested and not cached, pre-fetched or anything else. A browser will explicitly ask for confirmation if you're "reloading" a page requested via POST.
POST form sends data "in the background", while GET passes them in the URL. Does it have anything to do with the protocol or is it just browsers' convention?
"In the background" is the wrong way of thinking. The difference is between the URL and the request body. A GET request should not/must not have anything in its request body. Again, it's only passive information retrieval and must solely consist of HTTP headers. A POST request can have a request body. A request can have "data" both in its URL and in its body. Again, an assumption is that GET URLs can be shared and passed around, since it just links to information. POST requests on the other hand need to be very deliberate, so its information should not and doesn't need to be in the URL.
This question already has answers here:
When should I use GET or POST method? What's the difference between them?
(15 answers)
Closed 9 years ago.
What is the difference between the GET and POST form method except one(GET) send data from URL and post send directly ?
And if i use SSL then should i choose only post since get wont work ?
There really is nothing different between GET and POST. While GET uses URL visibly, you should not think that POST data is hidden in anyway, as this could create false sense of security. While POST indeed hides data from URL, it's still there, exposing slightly less data to a casual observer.
Even if HTTPS is used, preventing the data from being intercepted in transit, the browser history and the web server's logs will likely contain the full URL in plaintext, which may be exposed if either system is hacked. In these cases, HTTP POST should be used.
GET is used to read data. It's mostly used in search strings and in actions, where you get data from end point and where you don't modify anything. Because it's visible in URL, you can bookmark it for later use, that's not possible with POST.
POST is used to create, update and delete data in end point. For example form data is supposed to be sent as POST.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I want to implement a simple in-house table that tracks user page views on my website. Without targeting some specific hypothesis, what is useful data to store? Eventually I'll use it to build graphs or decision trees to better learn about our user base. This is static (no javascript).
Things I can think of:
URL accessed
HTTP refer[r]er
HTTP Accept Language
Browser-agent
Session id
User id (if logged in)
Time visited
It depends on how public your site is. If your site requires authentication you can have more controlled statistics because you can trace the user (visitors) history. In the case the user does not require authentication you are limited to the information provided by the SERVER VARIABLES: HTTP_USER_AGENT; REMOTE_USER; REMOTE_ADDR; REMOTE_HOST; REMOTE_PORT; HTTP_COOKIE; HTTP_USER_AGENT.
I have implemented something like this for some non-public site each time the user logs on to the site, the information I'm storing looks like:
User Key
Remote host IP
Date Logon
Last Request Datetime
Total time connected (minutes)
Last Request Minutes
Event/Action performed
Sounds like a good start,
I'd be inclined to store visitor IP address, and derived from that via a geo ip lookup the location of the visitor.
Also you could consider reverse dns'ing the IP to get an idea of the isp you're user is on, you might never use it but then again it could be useful if you have a report of downstream caching causing problems.