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 6 months ago.
Improve this question
I am new to REST API, and I am designing my own REST API for my web project.
Which of the followings is the better convention?
I want to access to the article that user ID 3 wrote.
/user/3/article
/article?user_id=3
Thanks.
Which of the followings is the better convention?
They are both fine.
/article?user_id=3 may prove more convenient if you are expecting to use HTML forms as a way of finding resources.
/user/3/article may prove more convenient if you expecting to use dot segments to describe other resource identifiers in the hierarchy.
What if I want to access to the fourth article that User ID3 wrote? /user/3/article/4 is appropriate? I think this hierarchy is unnecessarily deep.
Deep hierarchies are fine. Not using deep hierarchies are also fine.
In some designs, we'll use resource identifiers for items that are not part of the same hierarchy as the collection itself
context="/user/3/article" rel="item" href="/articles/4"
context="/user/3/article" rel="item" href="/articles/9"
context="/user/3/article" rel="item" href="/articles/16"
Think "web page with links"; if you can follow a link, you don't need a formula to compute the URI yourself.
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
So my friend needed to develop new API for creating item, so he developed:
POST /new/item
POST /item/new
PUT /new/item
PUT /item/new
All of them call the same underlying function and accept same parameters.
I recommended that he uses only 1 instead of 4, but he says that there is no down side and he's giving the option for anyone who wants to integrate with this API to use whatever personal variation they like.
Question: Is it really that there is no down side by doing this in the long run?
There is no downside in regards to functionality, but an API with redundant endpoints will probably be
Harder to maintain. If a change to the endpoint is needed, it may have to be made four times depending on the setup
Confusing for users of the API. While I imagine it's the intention behind this setup to catch typos in URLs and still allow the API to work, documentation on the endpoints will be bloated and harder to read
Lacking consistent naming. Ideally, there is a logic behind how endpoints are named, allowing users to infer what an endpoint does by its name and verb (GET, POST etc). Having multiple naming schemes makes it harder to understand the naming.
There is no meaningful upside to making redundant endpoints, and I would recommended to use POST /item for creating a new item.
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 2 years ago.
Improve this question
I have self-written API where urls are organized like:
GET /api/products
PUT /api/products/1
So there are controllers (ProductController.php, for example) and these controllers have four methods: get, post, put and delete.
Is this a right way to organize rest api?
If so, how to organize registration/authorization? Because both actions use POST method
Yes. I would recommend looking at how big companies are doing this kind of work. See how Github is structuring their API
Relies on what kind of authentication/authorization you want to use. Most companies choose Oauth with JWT, you could also use session-based authentication. For me, it's not clear what you exactly want to do. Maybe you can elaborate on that.
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 9 years ago.
Improve this question
I am trying to implement OOP in making an admin panel for my ecommerce website.
I am fairly new to OOP. I need few suggestions before starting my project.
I have:
Brands pages (Add, View) where admin can add brands (Companies) or view them in a grid;
categories / Subcategories;
products page (CRUD) with image upload;
customers;
orders;
payments;
Now the problem i am facing to jump in is that how to do it in OOP. For example:
Should i make seperate classes for every identity and add CRUD methods for every identity?
should i make a generic CRUD class and inherit it in every identity?
Perhaps its better for you to use a Framework like Symfony2, Codeigniter or something else. Then you can look at the important things and not the structure.
And the second is that you can look in existing Frameworks for good solutions to solve such problems.
The Framework gives you the structure to write your application with CRUD and many more.
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 5 years ago.
Improve this question
I have various documents some are large some are small, we have to draw up some form of model that would describe how a user interacts with each document when following them for a build. For example, a user might.
Follow Document 1 to Section 10 then be pointed to Document 2 to complete then return back to Section 10 in document 1 etc.
Has anyone ever drawn up some sort of chart to demonstrate this kind of thing for documentation, it is fairly standard for systems but i have never done it regarding documentation and I am just wondering if there is a formal method of doing this for documentation and is there any examples or standard guides to follow.
I think I would use an Activity diagram with Swimlanes for each document.
An alternative would be an IDEF0 diagram(may be appropriate if there are instructions for completing each document, and/or different roles for different steps)
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
For me it's got to be the Microsoft SQL Server Cast and Convert reference. I must love that page, I seem to visit it several times a day.
PHP Documentation for me - clear, concise, user tips (although these are not always correct and secure - pinch of salt etc). Also good for typing directly into an address bar if you know the function name, eg php.net/in_array - straight to the function's page.
The YUI documentation has had a good number of views over my last few projects...a good example of a clear and concise API
Definitely should be http://www.w3.org/TR/xslt :)
It depends a lot on what I'm doing and what my toolset is. In generaly these days it is probably Stroustrup's The C++ Programming Language.
From time to time, I still find that people need my services maintaining/fixing/adding new features to ASP site (VBScript) pages from time to time (yuck). The MSDN VBScript reference is usually all I need.