So I am updating a Play 1.2.x application with has the following setup
- controllers
- api
- Documents // create, update, read, delete, list
... // more controllers
- web
- Documents // list, read, etc...
.. // more controllers
The controllers in the api package render data as Json which is used by mobile clients (Android, iPhone).
Now I want to have a plain simple html web app consuming the api. So how can I consume the API from the controllers in the web package?
My goal is to avoid rewriting the api controllers logic in the web controllers logic.
Thanks!
Reusing methods between controllers is not the best practice in my opinion. Shared behavior should be coded in the model and both controllers can then use the same model methods.
Nevertherless if you want to do so, you can extract shared behavior in a public method in your apis controllers wich you can annotate as "#Util" and then call this method from your web controller.
There are not many details in your question, so I do not know if it applies, but usually when I implement REST APIs I let them serve their answers in different formats (JSON and HTML, and if you want JSONP and XML for instance).
The main idea is just to
check the request to know what format is required: either using the accept content type, the url extension, or even a parameter (and some more about it)
pick the right template (or skip a template if you have already correctly built your Json object)
In play there are different ways to do the first part, eg. through your routes: Request Content-Type in Play! Framework for REST webservices ; there is a specific page on Play documentation about this.
But the most important part in this answer is the second point: you should use the same controller and the HTML template should be able to render your page with the very same data that is sent back as json (or maybe a little more)!
NB. if you need to customize things a little more you can access the request object in the controller, check what the requested format is, and act accordingly to return appropriate data using the appropriate template!
Related
I am planning to have these endpoints for our REST APIs.
PUT /tenant/:tenantId/users/save/:username
POST /tenant/:tenantId/users/invite
GET /tenant/:tenantId/users/fetch
GET /tenant/:tenantId/users/fetch/:username
PATCH /tenant/:tenantId/users/activate/:username
POST /tenant/:tenantId/groups/save/
Verbs such as save/fetch/activate are from the consistency point of view. Are these RESTFul according to the REST principles? How should these be changed if at all? Any recommendations?
According to this REST Resource Naming Guide:
RESTful URI should refer to a resource that is a thing (noun) instead of referring to an action (verb) because nouns have properties which verbs do not have – similar to resources have attributes.
And also
URIs should not be used to indicate that a CRUD function is performed. URIs should be used to uniquely identify resources and not any action upon them. HTTP request methods should be used to indicate which CRUD function is performed.
So let's take your first URI as example
PUT /tenant/:tenantId/users/save/:username
Here you are using the verb save. As mentioned before you should not be indicating a CRUD operation in the URI, in this case using a POST would be more appropriate.Here is a guide with the purpose of each HTTP verb. Knowing this, I think that for example a more appropriate URI for that case would be something like
POST /tenants/:tenantId/users/:username
In this cases:
GET /tenant/:tenantId/users/fetch
GET /tenant/:tenantId/users/fetch/:username
you should remove the fetch because you are already telling through the GET verb that data is being fetched. Same goes for the 6th example.
But, this doesn't mean that you can't use verbs in your URIs, in fact there is a specific category called controller which as mentioned in the same guide:
A controller resource models a procedural concept. Controller resources are like executable functions, with parameters and return values; inputs and outputs.
Use “verb” to denote controller archetype.
This controllers resources could go well (I asume) with for example your
GET /tenant/:tenantId/users/activate/:username.
But I would think that the verb activate should go last:
GET /tenant/:tenantId/users/:username/activate
First note: REST doesn't care what spelling conventions you use for your resource identifiers. Once you figure out the right resources, you can choose any identifiers for them that you like (so long as those identifiers are consistent with the production rules defined in RFC 3986).
"Any information that can be named can be a resource" (Fielding, 2000), but its probably most useful to think about resources as abstractions of documents. We use HTTP as an application protocol whose application domain is the transfer of documents over a network.
GET
This is the method we use to retrieve a document
PATCH
PUT
POST
These methods all indicate requests to edit a document (specifically, to edit the request target).
PUT and PATCH are each ask the server to make its copy of a document look like the client's local copy. Imagine loading a web page into an editor, making changes, and then "saving" those changes back to the server.
POST is less specific; "here's a document that we created by filling in a web form, edit yourself appropriately". It is okay to use POST: after all, the web was catastrophically successful and we're still using POST in our form submissions.
The useful work is a side effect of these edits.
Are these RESTFul according to the REST principles?
Do they work like a web site? If they work like a web site: meaning you follow links, and send information to the server by submitting forms, or editing the webpages and submitting your changes to the server, then it is REST.
A trick though: it is normal in REST that a single method + request uri might have different useful side effects. We can have several different HTML forms that all share the same Form.action. Uploading changes to an order document might have very different effects if the edits are to the shipping address vs to the billing information or the order items.
Normal doesn't mean obligatory - if you prefer a resource model where each form request goes to a specific resource, that can be OK too. You get simpler semantics, but you support more resources, which can make caching trickier.
I am creating Cars store in Asp.Net for my school.
I built an Api Method:
[HttpGet("api/brands/{brandName}/models")]
public IActionResult Get(string brandName)
{
{
var model = _context.getBrandByName(brandName);
return Ok(model.Models.ToList());
}
}
An it works when I am checking it with Postman.
Now I would like User to choose brandName from selection list in the website and show him avaliable models.
In other words I dont know how to use this Api to get Data displayed.
Any help will be strongly appreciated
RESTful Web services are one way of providing interoperability between computer systems on the Internet. REST-compliant Web services allow requesting systems to access and manipulate textual representations of Web resources using a uniform and predefined set of stateless operations.
from Wikipedia.
This means, the REST API's only concern is to provide the data to work in a uniform and predefined set of operations, where those operations take the HTTP Verb that was used in consideration.
in your example, your GET route, should only be api/brands/{brandName}
the default in rest api, http verbs say:
GET - getting one element or a list
POST - creating
PUT - updating
DELETE - removing
in your application, the best approach would be something like:
GET /api/brands will get ALL existing brands
GET /api/brands/<brand_name> will get just one brand
POST /api/brands will create a new brand
PUT /api/brands will edit an existing brand
DELETE /api/brands will delete an existing brand
from your question:
Now I would like User to choose brandName from selection list on the website
the website would then request a GET to the route /api/brands to get the list of all of the brands.
This is the REST API part, it concerns ONLY in providing the right data to the system that request it.
if you want to create a website in order to CONSUME this data, you can easily create a new web project in your solution and request the data that the API provides, making the Website completely "blind" from where the data comes from, as it only asks for the data itself.
Making the whole system much easier for updated and maintainability.
In other words I dont know how to use this Api to get Data displayed.
The main purpose of REST API is to expose data not to display it by using any kind of UI framework.
If you think you need to manage the full stack of your application end-to-end. I mean from User interface to your database then you must think at implementing the V of the MVC pattern bu return a view and not just a data. ASP.Net Core can help you with that. Follow this tutorial, it explains a lot about this pattern in ASP.Net Core MVC.
I am working on building API in YII controller, we have a comment module which is an extension . I want to access comment extension's controller so that I can use the same functionality to be accessed for my API instead of creating one.
Can anyone tell me how can i do it?
Actually I am working on making API for my website. Where I have created a controller for API and accessing other controllers for functionality already exists. There's a functionality that exist in comment-module in extensions. And i need to access that Controller in comment-module. Hope this cleared my question asked above. And I need to access this function via Ajax as well, if possible. But should be accessed via API controller.
Specifying in case any confusion. My requirements would be:
accessing methods of comment-module controller in only 1 method in API Controller. In order to make my functionality centeralized.
comment-module should itself keep working.
and work with API controller as well.
Note: Please explain your solutions as well, I am not a genius in yii like you.
Move common functions into treat or inherit controller from extension.
Is it true that to implement a RESTful API, one has to implement a URL structure that looks like this
http://example.com/post/
http://example.com/post/123
where the /123 would be used for edit, delete
Another way to ask the question is: can a URL that looks like this be called RESTful?
http://example.com/script.php?method=get_title&blogid=123
You don't have to design your URI structure like that. It could also be /some_obscure_string/base64_encoded_title/unique_id. This could also be RESTful, depending on several other factors.
But there are several best practices on how to design URIs in a RESTful web application and being as simple and as human readable as possible is one of them.
Your example http://example.com/script.php?method=get_title&blogid=123 could also be RESTful, but the query parameters indicate that some kind of RPC- or RMI-over-HTTP is used instead.
To sum it up: Don't put too much thought into your URI design. This will come automatically with a good and proper RESTful design of your application.
The Idea behind REST is that every resource has it’s own URL and you use the different HTTP methods to interact with those resources. It makes sense to define the URL structure so that the hierarchy between different resources is reflected in the URL, but you don’t have to.
If you have URLs like this
/all-posts/
/first-post
/some-stuff/second-post
/third-post
you still could provide an RESTful API to this. The Idea is that a GET to /all-posts/ returns a list of the URLs of every post object and the client uses those URLs to interact with the resources. Basically the URLs should be treated as opaque data by the client.
As long as the URL that is embedded in the client doesn’t change you also could change the structure without having to change the client.
Your example URL probably doesn’t belong to a RESTful API, since it contains a method get_title. In REST a URL represents a thing. What is to be done with the thing (should it be modified, should it contents be retrieved, ...) is not part of the URL, for that REST uses the different HTTP methods.
A key aspect of REST is that the url is the resource. a uri like
http://example.com/script.php?etc-etc-etc
doesn't put the resource identifier in the resource portion of the uri. that's not to say that a RESTful API shouldn't ever use get parameters; in fact, that's just fine:
http://example.com/posts?sort=date_asc&offset=20&limit=10
might be a great way to get the URI's of the 3rd page of oldest posts. However, using get parameters in this way should only be used in requests where the method is also GET. PUT and especially POST methods should really use simple uri's with the resource that will be affected in only the path portion.
RESTful URI design is all about resources access and they should be structured in the RESTful manner, so you should not have any query strings.
e.g. of GET
authors/
authors/1
authors/1/books
authors/1/books/10
authors/1/books/10/summary
etc.
Anything and everything is called RESTfull these days, just look at some of the responses by it's inventor Dr Roy Fielding and you'll get some ideas. It is worth doing some reading on the subject.
P.S you do not need post,get etc in your URIs, HTTP protocol is at present mostly used for consuming REST APIs and you can pass verb as a part of the call. Also there is a concept of content negotiation i.e you can request any available format from REST API (json,xml atc).
The REST concept is really based on the fact that it is URL driven, and not driven by large data-blobs. With REST, you don't have to pass a giant soap request to invoke a method - your method call/object creation/whatever you want to do is invoked simply by the URL, and the verb you used vs that URL.
Example URLs:
GET http://del.icio.us/api/
GET http://del.icio.us/api/peej/tags/
GET http://del.icio.us/api/peej/tags/test
DELETE http://del.icio.us/api/peej/bookmarks/[hash]
The structure of your URLs doesn't matter. What does matter is that each URL identifies exactly 1 resource. Each resource can have multiple URLs that point to it but each URL should only point to 1 resource.
This can be helpful. Ref:
RESTful service URLs
So, I have a bunch of HTML is being stored in a SQLite database, and they link back and forth amongst themselves. When a user clicks to follow a link, that request needs to be serviced by pulling the appropriate HTML out of the database. This could result in needing to load images, which are also being stored in the database (this is a future thing; there are no images yet, but I'd like to be able to use them). I've looked through the WebKit documentation, but can't quite figure out how to make this happen. I've mostly looked at WebFrameLoadDelegate and WebResourceLoadDelegate, but I didn't see one that would let me catch the request, grab the appropriate content, and then send that in a response.
Ideas? I'm pretty new to Objective-C and Cocoa, but I think I'm mostly getting the hang of things.
How do the pages which are stored in the database link to each other? It is probably easiest if they use some sort of customer URL scheme to start with.
The approach I would use is to implement
-webView:resource:willSendRequest:redirectResponse:fromDataSource:
in your resource load delegate. If the request is for a resource that is actually located in your database, return a new[1] NSURLRequest which uses a custom URL protocol which points to the database resource:
x-my-scheme:///table/row
[1] Unless you are already linking amongst your resources with the custom URL scheme - then you can skip this step.
Then, implement a custom NSURLProtocol for x-my-scheme which knows how to retrieve the data from the database. The PictureBrowser sample gives a simple example of how this is done.