I did laravel RESTful app, and now I'm creating frontend with vue.js. But I dont understand this part:
If pages on the frontend requests products, categories and main information (like phone, email etc), this should be provided in different requests to the API? In this example, it will be separate request for products /api/products/get, categories /api/categories/get and like this? Or should I separate data for pages on backend and my API will return all of needed data with /api/get/mainpage?
Well, imho best practice will be to use endpoints related to data (e.g. /api/products/get).
It will ease your life because in this case you will need to write API once. And then just combine needed endpoints in requests for your frontend pages.
So if you will have to change your frontend, you won't need to change the backend.
Both parts become as independent as possible.
Related
I just watched a video, that says it's a bad practice to create API like that
/applications/getUser
/applications/deleteUser
/applications/getUserAndWeather
and from what I understood, it's a good design to create something like User and initialize post, get, put, delete properly.
but what if in my android application there is a page that shows all users in addition to weather, should I combine those two independent resources into one single API called UsersAndWeathers(GET) or create one called getUsersAndWeather. or should I create two separate endpoints and let android application calls both of in parallel?
I know all solutions would finally work, but which is the best design?
It's good to make small single-purpose API endpoints, because not every client might need both at the same time, the results might appear at different speeds, and might have different rules around when you need to refresh them. Just generally you don't want to combine every API response in one giant one.
HTTP requests are not that expensive, so your default should be to make 2 endpoints like
/users
/weather
There are certain cases where combining responses is a good idea, but you should only consider making these combined endpoints if you have such a reason. Until then, do the simple thing.
If you do find that reducing requests is something you need to do later, I would recommend you look into standard JSON response formats like HAL and JSON:API as they all have built-in syntax to support this use-case.
Basically, I'm looking for the absolute simplest way to add an email (which is effectively a Customer object with no other parameters) to my list of Customers. The use-case is a jQuery-based pop-up email collector that I'm writing because I'm not happy with/don't want to pay for more established solutions.
Everything is working correctly, except I'm stuck on how exactly to authenticate to my Shopify store. Via Javascript I can only perform a few API calls, none of which I need. There are also very complex solutions for creating full-fledged apps for Shopify which are able to do everything, but I think that's overkill for this one API request I need to make.
I know that all I need to do is make a POST request once authenticated per these instructions. What is the best way to do this?
If you want to create user from jQuery you can generate using AJAX POST call in appropriate URL generated using Private App, but be careful before placing authorization details in front end since it will be visible and any one can misuse it.
The better way is to create user using HTTP Post call from some server side language like JAVA or PhP or some language.
I primarily deal with REST json APIs at my work. So I am familiar with them. But for my own project I am trying out app engine as I believe it is a great fit.
I had already started writing my logic in python (using ferris), and in reading more on app engine I came across protorpc and cloud endpoints. But in most of the examples I have read, they seem to be doing the same just as I would do in a rest api. Make a request with json, and get a json response back. Or an error.
The main difference I see, is that in rest, the endpoints are based around a resource. And the HTTP verbs around them such as GET, POST, PUT, DELETE, etc. Where as in RPC, each request would have it's own endpoint rather than be based around a resource or model.
Both are requested with, and respond with json. So I think I am failing to see the benefit of using Google endpoints. Do they offer some other kind of benefit? I could maybe see better analytics tracking with endpoints. But wouldn't I still need to the use post http verb for modifying content?
Would any of this change if I was using certain frameworks? Like django. Although I am currently testing out Ferris which has a messaging system that deals with protorpc. Although, I have not been able to rest or yet.
So what am I missing? What are the benefits of endpoints over just making my object methods handle a json request. Do socket connections play into this at all?
You can do both by using endpoints to make a RESTful API.
protorpc/endpoints doesn't magically make your API RESTful. You have to make your API RESTful within the endpoints framework, which uses protorpc.
The benefits of using endpoints is that you can get a lot of the authentication work done easily (assuming you're going to use Google accounts), the serialization/deserialization is done for you, your client libraries can be generated for you, and more than just a Javascript client can be supported. If these things sound good, endpoints may be right for you. If these things don't apply, then maybe be more direct and use RequestHandlers yourself.
I was able to make a simple API using endpoints. It has 3 main resources: records, datasets and moves. A Record object is the smallest unit of data. The Dataset object is a group of records. And the Move object represents the event of a Dataset changing location.
My RESTful URIs look like this:
GET /records # Get list of records
GET /records/<id> # Get single record
POST /records # Create records
GET /datasets # Get list of datasets
GET /datasets/<id> # Get single dataset
POST /datasets # Create dataset
GET /moves # Get list of moves
GET /moves/<id> # Get single move
POST /moves # Create move
With this I can create data, organize it and move it around. I was able to do this completely within the endpoints framework on App Engine and it is RESTful.
Every resource online I have been able to find on the subject of restful api uri only covers standards and practices. But how does one develop a restful uri? This entire time I have developed web pages with extensions. How does one make a page without extensions? I am very confused.
Restful APIs are generally served by URL rewriting or forwarding; the 'pages' are not exactly pages but requests to a service. So something like this:
myco.com/people/jonny/house
Would be the resource for Jonny's house. But there is no page as such, just a service that sees that and either directly calls requestPerson('jonny').house or perhaps rewrites it as a page request that can be fulfilled.
Try to see it less as a file location and more as a request string, so it is more like myco.com/people, which is being asked for 'jonny/house'.
The two things to do when developing a RESTful interface are to decide on your data structure and decide on your request structure/mapping. So you have people and cars, and you permit requests for people, cars, or both. To some degree it is like querying a database via stored procedures; the procedures have to be set up to respond to queries, and they will do so in a predictable manner. The difference is that there is an engine managing the requests and responses, and the responses are generally in html format (though they can be JSON, XML, etc).
I have a website that revolves around transactions between two users. Each user needs to agree to the same terms. If I want an API so other websites can implement this into their own website, then I want to make sure that the other websites cannot mess with the process by including more fields in between or things that are irrelevant to my application. Is this possible?
If I was to implement such a thing, I would allow other websites to use tokens/URLs/widgets that would link them to my website. So, for example, website X wants to use my service to agree user A and B on the same terms. Their page will have an embedded form/frame which would be generated from my website and user B will also receive an email with link to my website's page (or a page of website X with a form/frame generated from my server).
Consider how different sites use eBay to enable users to pay. You buy everything on the site but when you are paying, either you are taken to ebay page and come back after payment, or the website has a small form/frame that is directly linked to ebay.
But this is my solution, one way of doing it. Hope this helps.
It depends on how your API is implemented. It takes considerably more work, thought, and engineering to build an API that can literally take any kind of data or to build an API that can take additional, named, key/value pairs as fields.
If you have implemented your API in this manner, then it's quite possible that users of this API could use it to extend functionality or build something slightly different by passing in additional data.
However, if your API is built to where specific values must be passed and these fields are required, then it becomes much more difficult for your API to be used in a manner that differs from what you originally intended.
For example, Google has many different API's for different purposes, and each API has a very specific number of required parameters that a developer must use in order to make a successful HTTP request. While the goal of these API's are to allow developers to extend functionality, they do allow access to only very specific pieces of data.
Lastly, you can use authentication to prevent unauthorized access to your API. The specific implementation details depend largely on the platform you're working with as well as how the API will be used. For instance, if users must login to use services provided by your API, then a form of OAuth may suffice. However, if other servers will consume your API, then the authorization will have to take place in the HTTP headers.
For more information on API best practices, see 7 Rules of Thumb When You Build an API, and a slideshow from a Google Engineer titled How to Design a Good API and Why That Matters.