New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide web-api support #303
Comments
I'm for implementing a base layer for rest APIs. Do you have any good ideas about requirements? |
yes, will post them later today here, with maybe some links to resources that also can be useful. |
More support for RESTful apps would be definitely a good idea. But if something like this is implemented, imo it should be a really solid foundation. I certainly don't wanna start to flame here, but just to give a negative example: SOAP-support in 1.x. The idea was really cool, and providing a SOAP service basically by simply annotating your methods could have been a killer feature. But the lack of interoperability with other technologies like java or .net really limited its usability. Also, it didn't provide some enhanced features like the ws-* extensions (never checked if they could have been implemented as extensions though, which would have been okay). For support of RESTful apps, I think some of the most important requirements would be:
I liked the REST with spring series, it explains a lot of the concepts around REST, so it's worth reading even if you don't use spring. |
I'm for never including sub-collection data directly. A reference in a good API should be URL. Can you elaborate about the following?
|
@samdark i think we need to create new topic on forum and discuss all there to avoid big comments here, what do u think? can u than create topic and link it here in comments? |
also this book covers some common features to implement with comparison of other API implementation, worth to read this https://blog.apigee.com/detail/is_your_api_naked_10_api_roadmap_considerations_part_1_visibility |
Agree, references should be (absolute) URLs. But simply never including sub-collections won't be the right solution imo. It might be a default, but there are enough use cases where the data you get is really useful and saves you from doing a lot of additional requests. As an example, think about a gallery that has a collection of categories, each category has a collection of images. If you include the sub-collection of images (maybe with a small page size like 5), you have enough data at hand to display some fancy category preview. And it saves you from introducing a special preview-image attribute in your category (which is purely presentation related and thus shouldn't be part of the resource). I'll wait for the suggested thread for elaborating on the other stuff. Or if you prefer having it all in one place, I'll comment here later. |
@bwoester batch queries will solve it. |
@Ragazzo thanks for the book, will read it. |
@samdark you mean like "get image-collections for categories 1-N"? |
About "include/ exclude resource attributes by default, with the possibility for the client to override these defaults": "Web API design" refers to it as "partial response" (p. 16). At least, this is the "possibility for the client to override" portion of what I meant. |
I implemented REST actions some time ago for a project with yii 1.1. They implement the basic CRUD actions and can handle normal CRUD via HTML but also REST requests by returning differen formats like JSON, csv or ical(used for date objects in this project). Here is a gist with the actions: And this is how a controller uses them: Hope this is good for inspiration and helps finding a good solution :) |
"Some time ago" made me remember. 😉 Here's my try. It's really work in progress, I did this "some time ago" and then stopped working on it, so it's a bit messy, not completed at all, but hopefully with a few ideas that might the helpful: https://github.com/bwoester/yii-rest-extension I read through the source and tried to remember how things were meant to work, put that all in the README.md and pushed it. |
I experiment on Yiinitializr-advanced boilerplate, and created https://github.com/tonydspaniard/yiinitializr-advanced/tree/master/api/extensions, allowing UrlManager to handle the routing (POST|GET|PUT|DELETE) hope it helps ps: It only supports Json format |
"Native" rest support would be amazing. I think it would be best handled by a new REST application extending \yii\web\Application. |
FYI: Created yii\web\VerbFilter yesterday which can be used together with these actions. |
Here is a proposal for RESTful routing: https://gist.github.com/cebe/5674918 |
issue yiisoft#303 Here is the proposal for RESTful routing syntax: https://gist.github.com/cebe/5674918
Does this proposal for restful routing imply you're concentrating on a solution where each controller implements rest behavior for its own model? |
Why should it? Can't see why other approaches should not work then? |
Other approaches would still work, sure. The proposal only made me think about pros and cons. For example, activating rest behavior on a per controller level might be easier to get started with. |
you mean not using |
Nope, I didn't mean using What I mean is: Most earlier approaches concentrated on a solution with one single controller that is responsible for all REST actions. Only the resource/ model on which the controller operated changed. Your new proposal seems to suggest handling REST actions in multiple controllers, one for each resource/ model. Thinking about it, I see both pros and cons. The nice thing is, it is closer to the normal yii request life cycle. People are used to it and thus it will be easy for them to start writing REST backends. On the other hand, you want have a uniform API for all your REST resources. You want the API to behave equally, regardless of the resource type you're operating on. Examples for this include the ability to accept and respond with different message formats like json or xml. Or to respond with appropriate http headers. |
Yeah, now I see your point. Both variants are good dependent on the situation. I do not concentrate on one of them. Both benefit from this new syntax and this is of course not the most important thing to implement for this issue. |
Issue 303 and 489 are both closed referencing to each other, is it an error? |
303 isn't closed. |
Sorry my error, I had bot issue open on 2 different tabs, I looked wrongly and posted same message on both. |
what exactly is your question? |
How off HttpBasicAuth for OPTIONS method? |
Override |
When I use two methods to autenticate, example:
HttpBasicAuth and HttpBearerAuth call same method in my class user:
I want validate in two different forms, I think is better if Basic and Bearer go to different methods then I don't need to check which autenticate form and I don't need to override anything. Am I wrong? How is the best way to do it? |
The format of your access token should be different. You can call different validation methods based on the format in findIdentityByAccessToken. |
@qiangxue Thanks for your reply. If I put on header: In the If I put on header unlike: In the I think the order I put on header can't influence on the result. I don't know if I'm doing something wrong or this expression is wrong:
|
Could you create a separate issue about this? Thanks. |
I'm not clear on the strategy for versioning. Here is an example: API v1 API v2 In this case, we need a migration to add the I guess there are multiple strategies to doing this -- I'm not clear what the options are, and what may be considered the best approach. |
As I understand it is supposed that each developer should implement his own strategy - as it is very specific per each app and each kind of differences between versions. You could have different versions of your Model and keep tack of backward compatibility of them (you can extend v1 from v2 or have completely different classes), have different versions of Components and utility code... so it seems for me very hard to have any generalized way. |
General concept is that if you are making breaking changes then you change major version, v1 to v2, but if you are making non-breaking changes you should update minor versions. The docs provide examples on how to do both I think. In the end, you're free to make your own implementations. |
Marked testing as complete |
@qiangxue is it safe now to implement it on applications with maybe some tests example since |
Yes. |
for our current design, what's the best way to implement URLs like this one: |
@fernandezekiel please open a new issue or ask in the forum or on IRC if it is just a question. |
I think it can be useful if Yii will provide some web-api support, for example REST, with catching event when request starts, also if Yii will provide some
CRestAction < CAction
, maybe other workaround can be here to fit REST, what do u think? Situation is common enough so if Yii will give developers some basis it can be good.Features to implement
File upload support (RC)moved to API: File upload support (RC) #4477Batch queries with transactions support and error handling. (GA or post GA)moved to #4478Searching and filtering (GA or post GA)moved to API: Searching and filtering #4479Automatic API Documentation Generation (e.g. via https://developers.helloreverb.com/swagger/) (GA or post GA)moved to REST API documentation #2684The text was updated successfully, but these errors were encountered: