This question already has answers here:
Which REST operation (GET, PUT, or POST) for validating information?
(6 answers)
Closed 5 years ago.
I want to implement a REST endpoint which general purpose is to validate complicated entity in JSON format.
So, the first question is which HTTP method should be used? We can't put JSON into body for GET method. POST and PUT are methods that should be used when some changes are done to the DB but validation doesn't make any changes.
And the second question is what resource name can be appropriate for such endpoint?
The main difference between POST and PUT is that PUT is idempotent while POST isn't.
So, the question is, if you run the same validation request twice, would you expect a different result? I guess no, so PUT probably is the best choice.
I you want to be effectively RESTful, one of the constraint is that an endpoint should target the resource you want to deal with, the HTTP method indicating what you want to do with it. So in your case, I would personally opt for:
PUT /api/v42/validation
As #RomanVottner proposed, you could also tackle this need by considering each request as a "new validation report generation", in which case POST would be more appropriate:
POST /api/v42/validations
Anyway, you're facing one of these edge cases where REST needs to be a bit tweaked, as this need is outside of the CRUD world.
My general rule is.. when you need a full JSON body, go with POST.
Have a post method like /validateJSON or something, GET would not work, PUT doesn't make sense, so go ahead with POST.
Refer to : Which REST operation (GET, PUT, or POST) for validating information?
Cheers.
Related
I am trying to work with a service that its creators describe as "restful"
To make a request to this service I have to post some Json e.g.
{
"#type" : "Something"
"$value" : 1
}
This is posted to a URL similar to this;
https://someSite.com/api/query/execute
No matter what the nature of the request, whether I am retrieving info, adding or updating it I must always use this URL (along with some header values to verify my credentials). The effects of posting to this service are determined by the JSON I send.
Depending on the nature of the call I will receive some JSON very similar to the sample above. This JSON never includes another URL (or part of one). It is always a "data object" i.e. a set of properties and their values. Sometimes I receive an empty response but know that the request has had an effect because I can view those effects through a website provided by the service provider
I have particular issues with ENUM values that I must send because I have no idea of the allowed values (they are always passed as strings)
No documentation has been provided for this service.
I am relatively new to RESTful services and JSON and would like to know whether this is truly a restful service, and if not why not?
Due to my lack of experience in this area I may have omitted some important information that would be required to properly answer this question. I will watch the comments closely and try to provide any additional clarification requested
know whether this is truly a restful service, and if not why not?
It isn't.
One of the main principles of REST is that "things" are identified by URLs. Having a single URL for all interaction with the API violates that principle.
I am trying to stick to the Restful design pattern for both JSON and HTML. My issue is the design for creating a new resource (amongst others, but this is the gist of the issue). IE:
JSON – POST to /resource creates a new resource.
JSON – GET to /resource returns a list of resources.
JSON – GET to /resource/{id} returns a resource.
HTML – POST to /resource creates a new resource.
HTML – GET to /resource returns a list of resources.
HTML – GET to /resource/{id} returns a resource.
All good so far – but I need a HTML form to actually create the data to send to the HTML POST. Obviously POST and GET already do things. I could use one of the below to return the HTML form:
HTML – GET to /resource?CREATE
HTML - GET to /resource?action=CREATE
HTML – GET to /resources/CREATE
But they seem like a kludge and not that intuitive.
Any thoughts or ideas?
EDIT - See my answer to my question below. At present this is (I consider) the best option.
I would indeed use something like /resources/create. If you want to allow for non-numeric identifiers, then this will not work. In that case you can identify a resource with a prefix, such as /resources/resource-{id} and then you can still use /resources/create.
I found this blog post really helpful to make URI scheme decisions: http://blog.2partsmagic.com/restful-uri-design/
In fact, you should leverage content negotiation (CONNEG) when you want to handle several formats within RESTful services.
I mean:
Set the Content-Type header to specify the type of sent data
Set the Accept header to specify the type of data you want to receive
The server resources should leverage these hints to make the appropriate data conversion.
In the case of JSON, the content type would be obviously application/json. For HTML form, you should leverage the content type application/x-www-form-urlencoded (or multipart/form-data if you want to upload files as well). See the specification for more details.
Otherwise, you shouldn't use action in URL since it's not really RESTful. The HTTP verb should determine the action to do on the resource. I mean, to create a resource, the POST method should be used. The GET method aims to retrieve the state of a resource.
For more details, you could have a look at this blog post:
Designing a Web API (i.e. RESTful service).
I have an answer. I'll use standard RESTful POST from a HTML page, but when I have no form parameters sent and my accept header is text/html, I'll send a HTML form to the requestor. Keeps RESTful URI design and allows a clean HTML form + process (2 step).
HTML - POST - /resources (with no form attributes) generates a HTML form
HTML - POST - /resources (with form attributes) adds a resource
JSON - POST - /resources (with form attributes) adds a resource
OK, it's not "strictly" RESTful as I'm POSTing but not creating a new resource so in theory I should use a GET for that, but it's the best of a mismatched design.
If anyone can provide a better solution, I'm still all ears :-)
I'd rather add and endpoint called /templates/ that returns a template/form/whatever you need for given action. It also seems that the server should be unaware of such form existence. It can accept or reject a request and it's client job to submit it in an appropriate format.
I guess that you mix processing the view with preparing RESTful endpoints. The backend site should be completely unaware of the fact that some sort of view/form is required. It's client job to prepare such form.
This question already has answers here:
HTTP GET with request body
(23 answers)
Closed 7 years ago.
I don't want to see so long parameters string in the URI. So, can GET method use json data?
In my situation, I need to filter the result given kind of parameters. If there are a lot of parameter, the length may exceed the limit of URI. So, is there best practice for this problem?
In theory, there's nothing preventing you from sending a request body in a GET request. The HTTP protocol allows it, but have no defined semantics, so it's up to you to document what exactly is going to happen when a client sends a GET payload. For instance, you have to define if parameters in a JSON body are equivalent to querystring parameters or something else entirely.
However, since there are no clearly defined semantics, you have no guarantee that implementations between your application and the client will respect it. A server or proxy might reject the whole request, or ignore the body, or anything else. The REST way to deal with broken implementations is to circumvent it in a way that's decoupled from your application, so I'd say you have two options that can be considered best practices.
The simple option is to use POST instead of GET as recommended by other answers. Since POST is not standardized by HTTP, you'll have to document how exactly that's supposed to work.
Another option, which I prefer, is to implement your application assuming the GET payload is never tampered with. Then, in case something has a broken implementation, you allow clients to override the HTTP method with the X-HTTP-Method-Override header, which is a popular convention for clients to emulate HTTP methods with POST. So, if a client has a broken implementation, it can write the GET request as a POST, sending the X-HTTP-Method-Override: GET header, and you can have a middleware that's decoupled from your application implementation and rewrites the method accordingly. This is the best option if you're a purist.
To answer your question, yes you may pass JSON in the URI as part of a GET request (provided you URL-encode). However, considering your reason for doing this is due to the length of the URI, using JSON will be self-defeating (introducing more characters than required).
I suggest you send your parameters in body of a POST request, either in regular CGI style (param1=val1¶m2=val2) or JSON (parsed by your API upon receipt)
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.
I'm new in this forum and I'm learning PHP from this night.
I want to send a form but I do not know the difference between:
<form action="page2.php" method="GET">
and
<form action="page2.php" method="POST">
Anyone could help me please ?
Thanks.
GET:
Parameters remain in browser history because they are part of the URL
Can be bookmarked.
GET method should not be used when sending passwords or other sensitive information.
7607 character maximum size.
Url example: page2.php?category=sport
POST:
Parameters are not saved in browser history.
Can not be bookmarked.
POST method used when sending passwords or other sensitive information.
8 Mb max size for the POST method.
Url example: page2.php
By convention HTTP GET is used for search forms while HTTP POST is used to change forms. A GET displays its information in the URL, publicly viewable, from which you can query the variables. A POST will not display its information. There is really no difference security wise.
If a GET request is used, the form parameters are encoded in the URL in what is called a query string.For example
www.someemailprovider.com/?login=joe#email.com&password=xxyz
A POST request, unlike a GET request, passes the form parameters in the body of the HTTP request, not in the URL.
Moreover GET is idempotent and POST is not that means If you call GET method on server nothing will be changed on server, but if you call POST then server will be changed may be a some additional data will be added in to the server, so GET is idempotent while POST is not.
Note
The main thing to keep in mind as a programmer is that defining your form to use the GET method does not protect against causing changes. You could use a GET request to do pretty much the same thing as a POST query. It’s just that browsers are generally coded to expect that POST requests will be used for things that will cause changes – like placing an order, or writing to a database, etc . GET requests should be used for pure queries that don’t affect anything on the server. So, one should always remember not to use GET requests for any action that would cause a change on the server – like ordering a big screen tv.
These are both HTTP request methods, not PHP exclusive.
$_GET is appended to end or URL. i.e. http://example.org/?foo=bar
Access it in PHP with:
$foo = $_GET['foo'];
or
$foo = $_REQUEST['foo'];
GET is used for information you don't mind people seeing, and can be manually typed into links and urls to get results.
$_POST is not visible in your URL, and generally is used after submitting a form.
Access it in PHP with:
$foo = $_POST['foo'];
or
$foo = $_REQUEST['foo'];
Read more about HTTP requests at http://www.w3schools.com/tags/ref_httpmethods.asp
I have a URI for a collection of resources called 'facts', and URIs for each 'fact' resource in that collection.
The form for creating a new 'fact' should be requested with a GET, I believe, but I'm having trouble deciding what URI it should be made to.
A GET to the collection URI should return a list of the 'fact' resource URIs. Each 'fact' URI should return its contents as a response to GET. The actual 'fact' creation would be a POST (or PUT, depending on the situation), of course.
I see a few options, but none seem satisfactory:
Add a 'fact form' URI which the 'facts' URI will reference. A GET to this URI gives the HTML form. Seems wrong to have another resource just for a description of a resource.
A POST made to the 'facts' URI without including any form data in the headers would return the form. Then after the user fills the form in, it would POST with the form data, and create the new 'fact' resource. This seems like an even worse approach.
Don't send the form over the wire, but include it as part of the API. This seems RESTful since a REST API should describe the media types, and a form can be made from a description of the 'fact' type. This is weird to implement. Maybe the REST service is separate from the regular web site, so that the actual HTML form request is at some URI apart from the REST API.
Include the HTML form as part of the 'facts' URI response.
To clarify, I'm trying to follow true REST architecture as specified by Roy Fielding, not half-baked RPC posing as REST.
edit: I'm starting to think #3 is on to something.
edit2: I think a solution is to have regular non-REST HTML navigation in a CRUD manner, and then the frontend makes AJAX REST calls as appropriate (or the backend makes internal calls to its REST API).
The reason I need to do the REST part of this service correctly is that I want to allow other non-HTML clients to interact with it later on.
In my mind, the only cleanly RESTful answers are 1 and 3.
As I see it, the description of the resource is a resource of its own. The question is whether you want to make this resource accessible through your application's API or if you want to make it part of the API itself.
For 1, it seems RESTful make the URIs something like this:
GET /facts -> all facts
GET /facts/1 -> returns fact 1 (obviously the id might be a word or something else)
GET /facts/create -> returns a form appropriate for creating a fact
POST /facts -> adds a fact
I think you're overcomplicating things a bit. A web browser is just not a perfect REST client, so you can't have a perfectly RESTful solution. In a perfect world, you would not need a form at all, because the web browser would know your media types and build the form itself.
Meanwhile, I suggest you just use what most REST frameworks would call an additional "view" on the resource to return a form:
E.g. /your/collectionresource?view=form, or /your/collectionresource;form