I got this problem, I have built a rest api and I don't know how to deal with this:
When the javascript client (Marionette.js) is in charge of making the views, I don't have problems, because as it is known, it just requests an url (e.g. example.com/user/37), the server retrieves a json with {id:'37', name:'Peter', age:'24'} (there is one controller class named User) and Marionette shows that data in the view. But if the user enter to example.com/user/37 by the browser it will show just {id:'37', name:'Peter', age:'24'} without any view. What can I do if I want to see the same view in both cases?
If you're trying to serve up HTML or JSON from the same endpoint then your server should be making that decision based on the request's Accept header. If the request's Accept header is application/json then your server should return just the JSON ortherwise return the HTML.
You can see that SoundCloud uses the same technique for returning XML or JSON from their API:
Resources are returned as XML by default, or JSON if a .json extension is appended to the resource URI. We encourage you to use JSON. You can also send an appropriate Accept header specifying the format you would like. For example, a request with the header Accept: application/json will return resources represented as a JSON document.
What you are trying to do is pratically impossible.
why ?
When your first enter the url example.com it's the server that responds with all the artifacts that compose your application (html, js, css ...) and the browser display it.
Now, when you enter ther url example.com/user/37 the server only sends the JSON data without any html, js or css, so the browser display the raw data he received.
What you are trying to do is to force the server to give two responses (JSON or html/js/css) depending on the user request.
You can do it, but it would be so complicated that's not worth the efforts.
Related
I'm in a situation where the server has some items that are identified by two keys: type and size. Clients don't know the items ID.
Clients should be able to perform a request to get a list of the items they want. e.g.:
"Give me the circle 40, the circle 30 and the square 40".
That's easy with a json body, but we must use a GET request. Given the problem this is not useful at all: /ids=1,2,3.
Should we make a:
Bizarre convention that clients should send type_size?
Still bizarre convention that clients should send type=size1,size2
GET request for every type?
POST request to act as a GET?
POST request that generates an ID to perform a subsequent GET
request?
How would you do this with an HTML web page?
You'd probably have a web page with a form, the form would have input controls so that the client can list the items they want. When the are finished filling in the form, the submit it.
At that point, the browser uses the data collected by the input controls to create an application/x-www-form-urlencoded document, and (because the method on the form is GET), use that document as the query part of the request uri.
GET /items?circle=30&circle=40&square=40
More generally, we can provide to the client a URI template that describes how information should be encoded into the URI.
But as far as HTTP is concerned: as long as the URI conforms to the production rules described by RFC 3986, it can be anything you want. As long as the client understands how to encode the information, and the server knows to decode the information the same way, you can do what you like.
I'm very new to API testing.
I'm trying to make use of Google Chrome's developer tools to understand and explore this subject.
Question 1:
Is it possible to get the response (possibly in JSON format) of a simple GET request using chrome developer tools?
What I'm currently doing is:
Open chrome developer tools
Go to Network tab
Clear existing logs
Send a post request simply by hitting a URL. e.g. https://stackoverflow.com/questions/ask
Check the corresponding docs loaded
Question 2:
What are the relevance "Reponse Headers" shown on the image above? I mean, am I correct to think that this is the response I am getting after doing the GET request?
Any help or references you can give are much appreciated!
If you want to test a rest api I sugest you get postman which is meant for that purpose.
Going to your questions:
Question 1: Is it possible to get the response (possibly in JSON
format) of a simple GET request using chrome developer tools?
The first point to make clear is that it is the server who will or will not send a json response to the browser. Not the browser who can choose to see any response as json.
If you send a GET request that the server responds with a json object or json array and the Content-type header is set to application/json, you will see that response already formated in the main window of the browser.
If the Content-type is set to text/html, for example, then you will still get the a json text as response in the main window but it won't be nicely formated. Depending on how the response was sent, sometimes you can see it nicely formatted by left clicking the browser window and selecting view source page.
For this you don't need developer's tools unless you want to see how long did it take to receive the response, or check the headers for some specific value, etc, but nothing to do with receiving the response or rendering it on screen.
Developer's tools is more usefull if you are working with javascript/jquery and/or if you are sending ajax requests (GET or POST). In these cases you can debug the function and also see the ajax request to check what actually went out from your browser and what was received as a response.
Question 2: What are the relevance "Reponse Headers" shown on the
image above? I mean, am I correct to think that this is the response I
am getting after doing the GET request?
In the response you get the two things, the headers, and the content. The json objects you see are part of the content not the headers.
The headers will tell the browser, for example, that the body is json (vs. an html documenet or something different), besides of other information like cache-control, or how long the body is.
Search for http headers for more information on which are teh standard headers.
To answer your questions narrowly:
Is it possible to get the response (possibly in JSON format) of a simple GET request using chrome developer tools?
Yes! Just click the Response tab, which is to the right of the Headers tab that's open in your screenshot.
What are the relevance "Reponse Headers" shown on the image above? I mean, am I correct to think that this is the response I am getting after doing the GET request?
Yes, these are the HTTP headers that were sent with the response to your request.
The broader question here is "how do I test a REST API?" DevTools is good for manual testing, but there are automated tools that can make it more efficient. I'll leave that up to you to learn more about that broad topic.
Is it possible to modify a property of a change request by using the OSLC-CM REST API of a change management system. The system that I'm trying to achieve that is Rational Change.
I can browse and query via the REST API, but to modify anything I need to resort to command line which is rather slow.
Is there a way?
BR,
Pawel
To update resources using the OSLC-CM REST API you simply just can use HTTP PUT. In order to do this, you'll first need the URL of the Change Request.
The steps to achieve this (using any HTTP client) are:
acquire URL for Change Request (usually done by query, or stored reference, etc)
Perform an HTTP GET on that URL, specifying a format for use in editing. This is done using 'Accept' header, some typical values would be 'application/xml', 'application/json' or 'application/rdf+xml'.
Note, it is a good idea to set the header 'OSLC-Core-Verson: 2.0' as well to ensure you are working with the 2.0 formats.
Once you have fetched the resource, modify the property to the value you want.
Using HTTP PUT, send the modified resource in the content body to the same URL you fetched the resource from.
Additionally you will most likely need to pass along some additional headers to help the server detect any possible conflict.
You should get back a 200 (OK) or 204 (No content) response on success.
An optimization would be to do the same steps as above but only request the properties of interest and only send them by using the selective properties feature of OSLC.
So I've finally got it working with some help from googlegroups
To recap what I've done so that someone else might benefit too (I really have searched for it and the IBM documentation is as in most of the cases not helping):
So to modify PR/CR' implement_actual_effort attribute on the Rational Change server the following procedure was successful (using Firefox REST plugin):
1. In Headers set: Accept to application/xml, Content-Type to application/xml
Put the oslc address of the cr i URL in my case it was:
http://[IP:PORT]/change/oslc/db/[DB hex ID]/role/User/cr/[web_encoded_name_of_the_CR]?oslc_cm.properties=change:implement_actual_effort
(note in browser http://[IP:PORT]/change/oslc/db/[DB hex ID]/role/User/cr/[web_encoded_name_of_the_CR] will open change page of the CR/PR)
In REST client set Method to GET and press SEND
Click on the Response Body (RAW), copy xml Body
Change Method to PUT, change the value of the attribute (in the xml in Body window)
Press SEND
Attribute should have been changed right now, and the response should be similiar to what you've sent, with the attribute showing the change.
Note that to change an attribute (called property from oslc point of view) one has to provide ?oslc_cm.properties=[properties delimited with comma]
and in the request body xml the same properties have to be present, if I remember correctly if the property isn't mentioned in the xml it will be set to default
I hope this helps someone
BR,
Pawel
I'm working on a REST API using the FOSRestBundle and I'd like to be able to use the same URL for returning HTML and JSON depending on the request Accept header; i.e. if you call the URL directly from a browser (Accept : text/html etc) HTML is returned from a twig file, if you are making an AJAX request (Accept : application/JSON etc), JSON is returned using the FOSRestBundle.
Currently I can get this to work by throwing a small if statement at the top of each function to check the request accept header, if it's asking for HTML it returns the twig file, if it's asking for JSON it hits the service.
You should rather send "Accept" header with your requests. Read content negotiation (“Accept” HTTP header) based routing in symfony2.0 and Format listener.
The request scope does not exist when run in command line mode, I had to remove request from each constructor and the problem disappeared.
I'm looking into a restful design and would like to use the HTTP methods (POST, GET, ...) and HTTP headers as much as possible. I already found out that the HTTP methods PUT and DELETE are not supported from the browser.
Now I'm looking to get different representations of the same resource and would like to do this by changing the Accept header of the request. Depending on this Accept header, the server can serve a different view on the same resource.
Problem is that I didn't find a way to tell my browser to change this header.
The <a..> tag has a type attribute, that can have a mime type, looked like a good candidate but the header was still the browser default (in Firefox it can be changed in about:config with the network.http.accept.default key).
I would partially disagree with Milan's suggestion of embedding the requested representation in the URI.
If anyhow possible, URIs should only be used for addressing resources and not for tunneling HTTP methods/verbs. Eventually, specific business action (edit, lock, etc.) could be embedded in the URI if create (POST) or update (PUT) alone do not serve the purpose:
POST http://shonzilla.com/orders/08/165;edit
In the case of requesting a particular representation in URI you would need to disrupt your URI design eventually making it uglier, mixing two distinct REST concepts in the same place (i.e. URI) and making it harder to generically process requests on the server-side. What Milan is suggesting and many are doing the same, incl. Flickr, is exactly this.
Instead, a more RESTful approach would be using a separate place to encode preferred representation by using Accept HTTP header which is used for content negotiation where client tells to the server which content types it can handle/process and server tries to fulfill client's request. This approach is a part of HTTP 1.1 standard, software compliant and supported by web browsers as well.
Compare this:
GET /orders/08/165.xml HTTP/1.1
or
GET /orders/08/165&format=xml HTTP/1.1
to this:
GET /orders/08/165 HTTP/1.1
Accept: application/xml
From a web browser you can request any content type by using setRequestHeader method of XMLHttpRequest object. For example:
function getOrder(year, yearlyOrderId, contentType) {
var client = new XMLHttpRequest();
client.open("GET", "/order/" + year + "/" + yearlyOrderId);
client.setRequestHeader("Accept", contentType);
client.send(orderDetails);
}
To sum it up: the address, i.e. the URI of a resource should be independent of its representation and XMLHttpRequest.setRequestHeader method allows you to request any representation using the Accept HTTP header.
Cheers!
Shonzilla
I was looking to do exactly the same thing (RESTful web service), and I stumbled upon this firefox addon, which lets you modify the accept headers (actually, any request headers) for requests. It works perfectly.
https://addons.mozilla.org/en-US/firefox/addon/967/
I don't think it's possible to do it in the way you are trying to do it.
Indication of the accepted data format is usually done through adding the extension to the resource name. So, if you have resource like
/resources/resource
and GET /resources/resource returns its HTML representation, to indicate that you want its XML representation instead, you can use following pattern:
/resources/resource.xml
You have to do the accepted content type determination magic on the server side, then.
Or use Javascript as James suggests.
ModHeader extension for Google Chrome, is also a good option. You can just set the Headers you want and just enter the URL in the browser, it will automatically take the headers from the extension when you hit the url. Only thing is, it will send headers for each and every URL you will hit so you have to disable or delete it after use.
Use some javascript!
xmlhttp=new XMLHttpRequest();
xmlhttp.open('PUT',http://www.mydomain.org/documents/standards/browsers/supportlist)
xmlhttp.send("page content goes here");